Этого треда уже нет.
Это копия, сохраненная 5 августа 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 5 августа 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
400 Кб, 2000x2000FFmpeg и общий кодирования видео тред №6
В прошлый раз мы снова почти не срались за кодеки весь тред, а культурно помогали друг другу с 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 кодирование гайд.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.
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 кодирование гайд.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 (
М)
7 Кб, 609x104Зачем в OBS добавили кодировщики AV1?
Не по теме, но в быдле добавили какой-то буст видосов, апающий размер и фпс. Теста ради попробовал, не так уж плохо, учитывая какой ужатый с трубы был исходник.
Ульра-платиновый вопрос - как нормально делать webm?
Попробовал тупо
ffmpeg -i RPReplay_Final1651382370.MP4 -t 167 repl.webm
- пыхтит на небольшом файле полчаса. Куда -hwaccel писать, чтоб быстра было? Ну или вообще как делать вебм-ки из mp4?
Попробовал тупо
ffmpeg -i RPReplay_Final1651382370.MP4 -t 167 repl.webm
- пыхтит на небольшом файле полчаса. Куда -hwaccel писать, чтоб быстра было? Ну или вообще как делать вебм-ки из mp4?
>>44888
Купить нормальный процессор.
Купить нормальный процессор.
>>44888
Не делай вебмки, они не открываются на ipad’е в сафари + больше девайсов поддерживают аппаратное декодирование h264.
Не делай вебмки, они не открываются на ipad’е в сафари + больше девайсов поддерживают аппаратное декодирование h264.
>>44888
ffmpeg -i RPReplay_Final1651382370.MP4 -t 167 -vcodec vp8 -acodec opus -b:a 128k -b:v 0 -crf 30 repl.webm
ffmpeg -i RPReplay_Final1651382370.MP4 -t 167 -vcodec vp8 -acodec opus -b:a 128k -b:v 0 -crf 30 repl.webm
>>45178
Ох уж эти токсичные фанатики, готовые забить на большинство девайсов только потому что "старое говно" или "эпло мусор".
Хорошо хоть люди, выкладывающие фильмы и сериалы на торренты, не такие неадекваты.
Ох уж эти токсичные фанатики, готовые забить на большинство девайсов только потому что "старое говно" или "эпло мусор".
Хорошо хоть люди, выкладывающие фильмы и сериалы на торренты, не такие неадекваты.
>>45185
Ты додик или притворяешься? Тогда кодека этого не было, соответственно в древних процессорах как говно мамонта, аппаратного кодирования тоже не могло быть. А то что эплодауны не могут кодек в говнобраузер добавить, чтобы хотя бы тупо воспроизводить, это исключительно проблемы япле и их гоев.
Да-да. Ведь там не h264 10 bit, аппаратно которое вообще почти нигде не реализовано. И всё давно выкладывают в hevc 10 bit.
>Ох уж эти токсичные фанатики, готовые забить на большинство девайсов только потому что "старое говно"
Ты додик или притворяешься? Тогда кодека этого не было, соответственно в древних процессорах как говно мамонта, аппаратного кодирования тоже не могло быть. А то что эплодауны не могут кодек в говнобраузер добавить, чтобы хотя бы тупо воспроизводить, это исключительно проблемы япле и их гоев.
>Хорошо хоть люди, выкладывающие фильмы и сериалы на торренты, не такие неадекваты.
Да-да. Ведь там не h264 10 bit, аппаратно которое вообще почти нигде не реализовано. И всё давно выкладывают в hevc 10 bit.
26 Кб, 442x639> Когда твой ноутбук 2016 года читает и поддерживает все кодеки аппаратно, кроме AV1.
Да, всё что старее, старое говно.
>>45185
Выблядки из эпл специально не добавляют поддержку самого лучшего кодека - у которого лучшая степень сжатия, свободного, без патентов, над которым работают множество компаний. Так что эту компанию можно смело слать нахуй
Выблядки из эпл специально не добавляют поддержку самого лучшего кодека - у которого лучшая степень сжатия, свободного, без патентов, над которым работают множество компаний. Так что эту компанию можно смело слать нахуй
>>45608
Мыльные VP9 и AV1 нужны только для экономии дискового пространства Youtube.
Мыльные VP9 и AV1 нужны только для экономии дискового пространства Youtube.
>>46065
Потому что vp9 для кодирования и максимального сжатия, а не для записи в реальном времени.
Потому что vp9 для кодирования и максимального сжатия, а не для записи в реальном времени.
>>46057
Уточняй, декодирование или энкодирование имеешь в виду под аппаратным ускорением.
Уточняй, декодирование или энкодирование имеешь в виду под аппаратным ускорением.
>>46083
Ютуб, Netflix
Ютуб, Netflix
>>44406 (OP)
Гайд жопный кал вообще. Новичок ничего не поймет и плюнет. Нахрена на него скидывать сразу какие-то параметры кодирования, если он даже базу не знает.
Гайд жопный кал вообще. Новичок ничего не поймет и плюнет. Нахрена на него скидывать сразу какие-то параметры кодирования, если он даже базу не знает.
>>46074
А нахрена? Фильмы вечность будут в vp9 кодироваться, тем более в экшн сценах. Да и у них не всех стоит жёсткой цели минимальную ширину канала ставить. Проще готовые h264, h265 крутить.
>>46076
Смотря какие. На redgif для более длинных роликов кодируется в vp9.
>>46077
А где они ещё могут быть? Разве что на сайтах встраивают вместо гиф.
А нахрена? Фильмы вечность будут в vp9 кодироваться, тем более в экшн сценах. Да и у них не всех стоит жёсткой цели минимальную ширину канала ставить. Проще готовые h264, h265 крутить.
>>46076
Смотря какие. На redgif для более длинных роликов кодируется в vp9.
>>46077
А где они ещё могут быть? Разве что на сайтах встраивают вместо гиф.
>>46057
С какой скоростью кодирует этот svt-av1 примерно? Aom просто миллиард лет это делает.
С какой скоростью кодирует этот svt-av1 примерно? Aom просто миллиард лет это делает.
>>46093
Попробуй - узнаешь
Попробуй - узнаешь
>>46353
Первый проход нужен чтобы кодировщик понял из чего состоит видео, как оно сжимается в каждом месте, он пробует сжать по твоим параметрам, и записывает информацию в отдельный файл. Если не написать степень сжатия, он сожмет по умолчанию, crf 28. В итоге во втором проходе ты напишешь другое значение, и его данные не совпадут, потому что он в первый раз рассчитывал на другие значения, и будет хуже качество
Первый проход нужен чтобы кодировщик понял из чего состоит видео, как оно сжимается в каждом месте, он пробует сжать по твоим параметрам, и записывает информацию в отдельный файл. Если не написать степень сжатия, он сожмет по умолчанию, crf 28. В итоге во втором проходе ты напишешь другое значение, и его данные не совпадут, потому что он в первый раз рассчитывал на другие значения, и будет хуже качество
>>46372
Вроде понятно, спасибо
Вроде понятно, спасибо
>>44406 (OP)
В некоторых видео ключевые кадры находятся слишком далеко друг от друга. Мне нужно увеличить их количество - один ключевой кадр на 1 или 2 секунды, при этом не потеряв в качестве видео. То есть желательно никак не менять пиксели, а вместо этого "взболтать" структуру кадров.
Было бы неплохо ещё и закодировать его в кодек с лучшим сжатием, но вряд ли это возможно без потери качества. Транскодирование в lossless сделает файл ещё более жирным.
В некоторых видео ключевые кадры находятся слишком далеко друг от друга. Мне нужно увеличить их количество - один ключевой кадр на 1 или 2 секунды, при этом не потеряв в качестве видео. То есть желательно никак не менять пиксели, а вместо этого "взболтать" структуру кадров.
Было бы неплохо ещё и закодировать его в кодек с лучшим сжатием, но вряд ли это возможно без потери качества. Транскодирование в lossless сделает файл ещё более жирным.
>>46435
Нахуя? От этого точно потеряется качество. С помощью команды -g 30, число кадров раз в которую ставится ключевой кадр
Нахуя? От этого точно потеряется качество. С помощью команды -g 30, число кадров раз в которую ставится ключевой кадр
>>46473
Почему? По идее, он должен декодировать промежуточные кадры, но не показывать их на экране готовыми картинками, как плеер, а сохранить эти картинки в ключевые кадры.
>От этого точно потеряется качество
Почему? По идее, он должен декодировать промежуточные кадры, но не показывать их на экране готовыми картинками, как плеер, а сохранить эти картинки в ключевые кадры.
>>46568
Можно в ffv1 закодировать, это кодек без потерь где нет промежуточных кадров, только ключевые
Можно в ffv1 закодировать, это кодек без потерь где нет промежуточных кадров, только ключевые
>>46627
Вменяемым сжатием даже не пахнет.
>Latest releaseVersion 3 (FFV1.3) 3 August 2013; 8 years ago
Вменяемым сжатием даже не пахнет.
Было несколько видео на несистемном диске, которые случайно удалил. Ничего нового на диск не писал. Рекувой восстановил, состояние было указано - excellent, весят как и должны. Но файлы не воспроизводятся.
Что надо подправить, чтобы они открывались?
Что надо подправить, чтобы они открывались?
>>46667
Тогда UT Video.
Тогда UT Video.
>>46701
Попробуй перепаковать.
Попробуй перепаковать.
>>46667
Ты еблан, там несколько версий есть, 3 активно развивается. И даже первая сжимает без потерь лучше чем 264 и 265
Ты еблан, там несколько версий есть, 3 активно развивается. И даже первая сжимает без потерь лучше чем 264 и 265
Попробовал UT и FFV1.
UT – 2,48 ГБ.
FFV1 со стандартным GOP 250 – 1,85 ГБ.
FFV1 с GOP 1 – 1,86 ГБ.
Декодирование UT нагружает i3 7100 на 10-15%.
Декодирование FFV1 нагружает i3 7100 на 55-60%.
UT – 2,48 ГБ.
FFV1 со стандартным GOP 250 – 1,85 ГБ.
FFV1 с GOP 1 – 1,86 ГБ.
Декодирование UT нагружает i3 7100 на 10-15%.
Декодирование FFV1 нагружает i3 7100 на 55-60%.
Дублирую! >>3146907 →
Пробовал
-map 0
-disposition:a:0 default (поставить японскую по умолчанию)
-disposition:a:1 none (убрать значение по умолчанию для дубляжа)
эффекта не возымело. Как так вообще получилось, что после склейки вторая дорожка тоже стала дефолтной?
Пробовал
-map 0
-disposition:a:0 default (поставить японскую по умолчанию)
-disposition:a:1 none (убрать значение по умолчанию для дубляжа)
эффекта не возымело. Как так вообще получилось, что после склейки вторая дорожка тоже стала дефолтной?
10 Кб, 764x75>>46946
Оказалось, что вместо
-disposition:a:x none
нужно
-disposition:a:x 0
так как none не задокументированный аргумент, о чем индус на стаке не удосужился упомянуть. Как итог у меня не работало, билд от BtBN.
Оказалось, что вместо
-disposition:a:x none
нужно
-disposition:a:x 0
так как none не задокументированный аргумент, о чем индус на стаке не удосужился упомянуть. Как итог у меня не работало, билд от BtBN.
>>44888
Если есть видеокарта NVIDIA,то вроде -hwaccel cuda
Если есть видеокарта NVIDIA,то вроде -hwaccel cuda
Можно ли как-то в скрипте отследить и пайпнуть куда-то сообщение об ошибке?
Какой стандартный пресет у SVT-AV1? На 0 конечно мемно на моей рязани 2600 делает, 2 секунды в полчаса. На амуде вообще нет смысла или от поколения зависит?
>>47807
Работать то работает. Я так понял, что на новых процах он работает сильно быстрее, нет?
Работать то работает. Я так понял, что на новых процах он работает сильно быстрее, нет?
>>47825
Да не сказать что очень. Вот сравнение preset 5 с vp9 good.
Да не сказать что очень. Вот сравнение preset 5 с vp9 good.
>>47838
У меня скрипт на питоне, который все видео ищет в папке, где лежит, и по очереди кодирует.
У меня скрипт на питоне, который все видео ищет в папке, где лежит, и по очереди кодирует.
>>44406 (OP)
В пособии по 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 (принимается критика)
В пособии по 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, и того ещё, насколько при этом растёт соотношение качества и объёма файла.
>>44406 (OP)
Убери вот эту беспруфную хуйню в разделе Opus. Выделил жирным и подчеркнул
Объяснять и доказывать, надеюсь не нужно. Мп3 320 это уровень качества, который уже неотличим от лосслесс в 99% случаев. Опус хорош только на низких битрейтах своей дикой скоростью кодирования и относительно низким количеством слышимых артефактов. Он никогда не был полной заменой музыкальных кодеков
На 256/320кбит опус проигрывает и ворбису, и мп3. Чтобы 160кбит опус давал меньше артефактов чем мп3 320 это вообще бред. Только если сравнивать с первой версией мп3 из 1993 года, может быть где-то там
> Гайд по кодированию от анона из треда №5 (принимается критика): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
Убери вот эту беспруфную хуйню в разделе Opus. Выделил жирным и подчеркнул
> Оптимальный битрейт 160k, используется на ютубчике, по тестам звучит лучше чем 320k mp3
Объяснять и доказывать, надеюсь не нужно. Мп3 320 это уровень качества, который уже неотличим от лосслесс в 99% случаев. Опус хорош только на низких битрейтах своей дикой скоростью кодирования и относительно низким количеством слышимых артефактов. Он никогда не был полной заменой музыкальных кодеков
На 256/320кбит опус проигрывает и ворбису, и мп3. Чтобы 160кбит опус давал меньше артефактов чем мп3 320 это вообще бред. Только если сравнивать с первой версией мп3 из 1993 года, может быть где-то там
>>48594
"Музыкальные" очевидно те, где артефактов почти не слышно, либо вообще не слышно по всему спектру на не слишком огромных битрейтах
Опус к ним не относится. Его применяют только на ютубе и в приложениях для голосовой связи
Алсо тащи пруфы, где там опус 160кбит превосходит 320кбит мп3
Если методику не знаешь — берешь исходник в любом лосслес формате, конвертишь в опус и мп3. С помощью спец софта вычитаешь из сигнала опуса сигнал лосслес и из мп3 лосслес. Получаешь отдельно артефакты для опкса и для мп3, и вбрасываешь их сюда + скриншоты спектрограмм артефактов
Глупость это хуета написанная про маняпревосходство опуса над всем сущим. Его удел это низкие битрейты, например длинные вебмки, которые с трудом помещаются в лимит даже без звука. Или вебм в которых музыкальная составляющая вообще не играет роли, например если в ролике в основном просто пиздеж голосом
"Музыкальные" очевидно те, где артефактов почти не слышно, либо вообще не слышно по всему спектру на не слишком огромных битрейтах
Опус к ним не относится. Его применяют только на ютубе и в приложениях для голосовой связи
Алсо тащи пруфы, где там опус 160кбит превосходит 320кбит мп3
Если методику не знаешь — берешь исходник в любом лосслес формате, конвертишь в опус и мп3. С помощью спец софта вычитаешь из сигнала опуса сигнал лосслес и из мп3 лосслес. Получаешь отдельно артефакты для опкса и для мп3, и вбрасываешь их сюда + скриншоты спектрограмм артефактов
Глупость это хуета написанная про маняпревосходство опуса над всем сущим. Его удел это низкие битрейты, например длинные вебмки, которые с трудом помещаются в лимит даже без звука. Или вебм в которых музыкальная составляющая вообще не играет роли, например если в ролике в основном просто пиздеж голосом
>>48605
Ну так и вбрось, раз утверждаешь, только желательно тесты не на реалтеке в мат. плату встроенном делай, чтобы наводок от хардвари избежать.
> Получаешь отдельно артефакты для опкса и для мп3, и вбрасываешь их сюда + скриншоты спектрограмм артефактов
Ну так и вбрось, раз утверждаешь, только желательно тесты не на реалтеке в мат. плату встроенном делай, чтобы наводок от хардвари избежать.
>>48605
> например если в ролике в основном просто пиздеж голосом
> Opus — последнее слово в области lossy кодирования аудио. Сочетает в себе новейшие разработки — низколатентный кодек CELT от Xiph.Org и ориентированный на речь кодек SILK, разработанный Skype. Оба эти кодера в значительной степени модифицированы и благодаря этому очень эффективно взаимодействуют. Opus может не только незаметно переключаться между реализациями SILK и CELT, но также и работать в гибридном режиме — когда SILK кодирует диапазон до 8 кГц с линейным предсказанием, а CELT — всё что выше, с использованием МДКП.
> Opus отличается наиболее совершенной на сегодня психоакустической моделью и непревзойдённой гибкостью битрейта (от 1 до 256 кбит/с на канал, с приращением ±0.4 кбит/с).
>>48611
Всё так. Если почитать ветку, я пишу о том же самом
>>48609
На гитхабе абсолютно беспруфное утверждение сенсационного характера. Так что ждём пруфов сначала от автора того утверждения. Либо пусть убирает сомнительную информацию
Кодирование на процессоре выполняется. Это сравнение можно вообще без звуковой карты выполнить только с помощью монитора и мышки
Даже если слушать, искажения от реалтека будут несравнимо малы по сравнению с артефактами опуса 160кбит. Современные цапы практически невозможно отличить вслепую, кроме самых самых хуевых цапов. Реалтеки 700-1000 серии к самым хуевым не относятся
Всё так. Если почитать ветку, я пишу о том же самом
>>48609
> Ну так и вбрось, раз утверждаешь
На гитхабе абсолютно беспруфное утверждение сенсационного характера. Так что ждём пруфов сначала от автора того утверждения. Либо пусть убирает сомнительную информацию
> только желательно тесты не на реалтеке в мат. плату
Кодирование на процессоре выполняется. Это сравнение можно вообще без звуковой карты выполнить только с помощью монитора и мышки
Даже если слушать, искажения от реалтека будут несравнимо малы по сравнению с артефактами опуса 160кбит. Современные цапы практически невозможно отличить вслепую, кроме самых самых хуевых цапов. Реалтеки 700-1000 серии к самым хуевым не относятся
>>48643
Не, ну про 160 opus и 320 mp3 неотличимое, здесь будет посос, по спектрограммам уж точно. Это автор какую-то хуйню прогнал непроверенную. Никогда не верьте гайдам с двача.
> На гитхабе абсолютно беспруфное утверждение сенсационного характера. Так что ждём пруфов сначала от автора того утверждения.
Не, ну про 160 opus и 320 mp3 неотличимое, здесь будет посос, по спектрограммам уж точно. Это автор какую-то хуйню прогнал непроверенную. Никогда не верьте гайдам с двача.
>>48590
Ничего подобного. Тестов в инете полно. Плюс в мп3 есть баг, который в начале добавляет пустоту.
>Мп3 320 это уровень качества, который уже неотличим от лосслесс в 99% случаев
Ничего подобного. Тестов в инете полно. Плюс в мп3 есть баг, который в начале добавляет пустоту.
28 Кб, 1024x1024>>48721
Действительно странный, постил бы просто полезные твики и не смущал анончиков
Действительно странный, постил бы просто полезные твики и не смущал анончиков
152 Кб, 736x736А то, что он постит 7zip, вместо винрара, никого конечно не смушщает, анимешников немаэ, ироглифы нинужны, ироглифоблядь не человек
>>48729
На винде криво отображаются, никакой клеартуп не спасает, вот на маке отлично.
На винде криво отображаются, никакой клеартуп не спасает, вот на маке отлично.
>>48590
Держи пруфы
https://wiki.hydrogenaud.io/index.php?title=Opus
http://listening-test.coresv.net/results.htm
Тесты причём старые, современный opus ещё лучше выдает результаты, где-то на форумах есть новые тесты
>>48695
Проиграл с долбоеба, этот архив был создан когда подняли скандал, чтоб легче было сделать обратную разработку, т.к. в старых версиях не был накинут обфускатор
Держи пруфы
https://wiki.hydrogenaud.io/index.php?title=Opus
http://listening-test.coresv.net/results.htm
Тесты причём старые, современный opus ещё лучше выдает результаты, где-то на форумах есть новые тесты
>>48695
Проиграл с долбоеба, этот архив был создан когда подняли скандал, чтоб легче было сделать обратную разработку, т.к. в старых версиях не был накинут обфускатор
>>48590
Ебать дегенерат https://wiki.xiph.org/OpusFAQ
> На 256/320кбит опус проигрывает и ворбису, и мп3. Чтобы 160кбит опус давал меньше артефактов чем мп3 320 это вообще бред. Только если сравнивать с первой версией мп3 из 1993 года, может быть где-то там
Ебать дегенерат https://wiki.xiph.org/OpusFAQ
>>48751
А где спектрограмма, полученная с помощью RMMA? Вот сюда её давай.
Зачем вообще это хостить, зачем вообще этому делать обратную разработку, лол.
> listening test
А где спектрограмма, полученная с помощью RMMA? Вот сюда её давай.
> Проиграл с долбоеба, этот архив был создан когда подняли скандал, чтоб легче было сделать обратную разработку, т.к. в старых версиях не был накинут обфускатор
Зачем вообще это хостить, зачем вообще этому делать обратную разработку, лол.
>>48751
Так это и сравнивали на битрейте 96 кбпс, ты давай сравнение опущ 160 и мрз 320.
> Тесты причём старые, современный opus ещё лучше выдает результаты, где-то на форумах есть новые тесты
> --bitrate 96
Так это и сравнивали на битрейте 96 кбпс, ты давай сравнение опущ 160 и мрз 320.
>>48772 (Del)
Нет, год рождения
https://hydrogenaud.io/index.php?topic=117489.0
Короче, может opus 160 звучит и не лучше mp3 320, но точно не хуже, разницу отличить невозможно
Нет, год рождения
https://hydrogenaud.io/index.php?topic=117489.0
Короче, может opus 160 звучит и не лучше mp3 320, но точно не хуже, разницу отличить невозможно
>>48779
Тогда правь шапку, охуевший.
> Короче, может opus 160 звучит и не лучше mp3 320, но точно не хуже, разницу отличить невозможно
Тогда правь шапку, охуевший.
НУ ВСЁ, ВЫ ДОИГРАЛИСЬ НАХУЙ, сейчас я проведу НАСТОЯЩИЕ тесты
https://disk.yandex.ru/d/s853E0oB1v_v6Q — тут результаты в виде двух файлов с артефактами + исходник
OPUS 160k хуже чем MP3 320k, т.к. дает гораздо больше слышимых артефактов на большей громкости
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.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кгц
>>48751
Одна ссылка не открывается. Во второй MP3 кодируют с параметром v5, это 130кбит/сек
В ОППосте же висит информация, что OPUS 160кбит якобы лучше, чем MP3 320кбит. То что он лучше мп3 130кбит я не отрицаю
https://disk.yandex.ru/d/s853E0oB1v_v6Q — тут результаты в виде двух файлов с артефактами + исходник
OPUS 160k хуже чем MP3 320k, т.к. дает гораздо больше слышимых артефактов на большей громкости
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.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кгц
>>48751
Одна ссылка не открывается. Во второй MP3 кодируют с параметром v5, это 130кбит/сек
В ОППосте же висит информация, что OPUS 160кбит якобы лучше, чем MP3 320кбит. То что он лучше мп3 130кбит я не отрицаю
НУ ВСЁ, ВЫ ДОИГРАЛИСЬ НАХУЙ, сейчас я проведу НАСТОЯЩИЕ тесты
https://disk.yandex.ru/d/s853E0oB1v_v6Q — тут результаты в виде двух файлов с артефактами + исходник
OPUS 160k хуже чем MP3 320k, т.к. дает гораздо больше слышимых артефактов на большей громкости
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.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кгц
>>48751
Одна ссылка не открывается. Во второй MP3 кодируют с параметром v5, это 130кбит/сек
В ОППосте же висит информация, что OPUS 160кбит якобы лучше, чем MP3 320кбит. То что он лучше мп3 130кбит я не отрицаю
https://disk.yandex.ru/d/s853E0oB1v_v6Q — тут результаты в виде двух файлов с артефактами + исходник
OPUS 160k хуже чем MP3 320k, т.к. дает гораздо больше слышимых артефактов на большей громкости
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.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кгц
>>48751
Одна ссылка не открывается. Во второй MP3 кодируют с параметром v5, это 130кбит/сек
В ОППосте же висит информация, что OPUS 160кбит якобы лучше, чем MP3 320кбит. То что он лучше мп3 130кбит я не отрицаю
>>48950
В данном случае, какая бы пиздатая психоакустическая модель не была, артефакты опуса играют очень громко, их будет слышно так или иначе. В каких-то треках ты это не заметишь, а в каких-то сразу услышишь грязь. У мп3 320 же тихое шуршание и я не спорю, что на 160кбит у мп3 результат был бы хуже
В данном случае, какая бы пиздатая психоакустическая модель не была, артефакты опуса играют очень громко, их будет слышно так или иначе. В каких-то треках ты это не заметишь, а в каких-то сразу услышишь грязь. У мп3 320 же тихое шуршание и я не спорю, что на 160кбит у мп3 результат был бы хуже
>>48818 (Del)
Твоя борьба.
Твоя борьба.
>>48951
А на 320кбит у опуса? И что там у него с частой дискретизации, вроде 44100 раньше не умел и автоматически повышал до 48000, что как бы не улучшало какчества.
> на 160кбит у мп3 результат был бы хуже
А на 320кбит у опуса? И что там у него с частой дискретизации, вроде 44100 раньше не умел и автоматически повышал до 48000, что как бы не улучшало какчества.
>>48979
Меня интересуют артефакты, не с точки зрения звука, я слушаю пердёжь из гениусов за 100 рублей, а в том, насколько хорошо кодек адаптирован к высоким битрейтам или его психосексуальная модель вносит типичные опусовские искажения на любом битрейте, а не по мере необходимости.
Меня интересуют артефакты, не с точки зрения звука, я слушаю пердёжь из гениусов за 100 рублей, а в том, насколько хорошо кодек адаптирован к высоким битрейтам или его психосексуальная модель вносит типичные опусовские искажения на любом битрейте, а не по мере необходимости.
>>48978
Сегодня уже лень это делать, может завтра вечером ещё дополнительно поогоню опус, ворбис, аац на 320кбит
Это не брал в расчет, при ресемплинге артефакты "микроскопические" по сравнению с любым кодеком в 320кбит. Не уверен, можно ли их вообще услышать в реальных условиях
> А на 320кбит у опуса?
Сегодня уже лень это делать, может завтра вечером ещё дополнительно поогоню опус, ворбис, аац на 320кбит
> И что там у него с частой дискретизации, вроде 44100 раньше не умел и автоматически повышал до 48000
Это не брал в расчет, при ресемплинге артефакты "микроскопические" по сравнению с любым кодеком в 320кбит. Не уверен, можно ли их вообще услышать в реальных условиях
>>48947
Твой математический тест полная хуйня, можешь сколько угодно сидеть и что-то там вычитать, это ни о чём не говорит.
Имеет вес только субъективные прослушивания у разных людей в слепую
Твой математический тест полная хуйня, можешь сколько угодно сидеть и что-то там вычитать, это ни о чём не говорит.
Имеет вес только субъективные прослушивания у разных людей в слепую
>>49005
Вслепую опус 160 кбит будет точно также хуже, чем мп3 320. В самых вырожденных случаях они будут неотличимы, но никак не лучше
Вслепую опус 160 кбит будет точно также хуже, чем мп3 320. В самых вырожденных случаях они будут неотличимы, но никак не лучше
>>49046
Добавил в ту же папку ещё opus 320, vorbis 320 артефакты.
Пик1 - опус
Пик 2 - мп3
Пик 3 - ворбис
Ну разницу тут уже с лупой нужно искать. У опуса на 320кбит чисто по плотности искажений всё хуже, да ещё и распределение идет больше на средние частоты. Ворбис и мп3 тут адекватнее справляются мп3 на самом деле не так плох, дохуя он уводит в низкие частоты, где артефакты почти невозможно расслышать, и в самые верхние, где ситуация аналогичная
Но по факту на 320кбит я уже не отличаю нихуя эти файлы от lossless. Как ни старался, не слышу разницу. Даже 160кбит опус с трудом могу отличить, и то не на любой песне.
AAC не получилось. Подозреваю проблема в конкретном кодеке, либо расчете времени файла у ффмпег. После кодирования я получаю расхождение в 0.013сек, которое руками искать я ебал если честно
А Wav попробовал пожать. Не нашел способов, кроме как перевести в 8 бит и снизить sample rate. Но если снизить sample rate до 320кбит/сек, качество падает просто пиздец. Хз может есть какие-то лосси кодеки, но я не нашел
Добавил в ту же папку ещё 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.
Что это за жидовские фокусы? Как оно работает в плане формата и разрешения? И где здесь исходник?
Нашёл ссылку на картинку:
https://i-viaplay-com.akamaized.net/viaplay-prod/342/548/1574760460-8b604476d0e29d15c099dc0d82b55fbe84dc06a3.jpg?width=1600&height=900
Написано ведь, что jpg. А скачивается webp.
Причём, если удалить из ссылки всё после вопросительного знака включительно, то будет уже 1920x1080, а не 1600x900.
Что это за жидовские фокусы? Как оно работает в плане формата и разрешения? И где здесь исходник?
>>49227
Сервер принимает запрос, парсит путь, параметры, твой юзер агент и решает, что выдавать тебе отталкиваясь от этого.
Если хочешь jpg, качай wget’ом или curl’ом или меняй юзер агент в браузере.
Исходник может быть jpg, а webp уже из него сделан, а может исходник в лосслесс формате и жпг и вебп сделаны из него, но судя картинке вряд ли.
Сервер принимает запрос, парсит путь, параметры, твой юзер агент и решает, что выдавать тебе отталкиваясь от этого.
Если хочешь jpg, качай wget’ом или curl’ом или меняй юзер агент в браузере.
Исходник может быть jpg, а webp уже из него сделан, а может исходник в лосслесс формате и жпг и вебп сделаны из него, но судя картинке вряд ли.
>>49204
Так это, файлы же есть на послушать
Если нужны выводы, то чисто по графикам и прочей хуйне
Все что ниже 192кбит — это opus
Выше 192кбит — vorbis, mp3, возможно aac
В зависимости от трека/наушников, запросто может быть такое, что опус 160кбит неотличим от лосслесс
Так это, файлы же есть на послушать
Если нужны выводы, то чисто по графикам и прочей хуйне
Все что ниже 192кбит — это opus
Выше 192кбит — vorbis, mp3, возможно aac
В зависимости от трека/наушников, запросто может быть такое, что опус 160кбит неотличим от лосслесс
216 Кб, 2510x730>>49286
Ну ладно, заменю твоим. Скачал через curl -O, хз почему поломано. Просто хотелось jpg без лишнего перекодирования.
Ну ладно, заменю твоим. Скачал через curl -O, хз почему поломано. Просто хотелось jpg без лишнего перекодирования.
>>49292
Jpg всегда нужно оптимизировать с помощью pingo, пару мегабайт экономит, и всякие такие ошибки исправляет
Jpg всегда нужно оптимизировать с помощью pingo, пару мегабайт экономит, и всякие такие ошибки исправляет
>>48947
Вот именно. За это я и ценю 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 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"
>>50823
Поясни.
Поясни.
>>50788
Тупой дегрель, желаю скорее кирпича твою телефончику. Опус был, есть и будет самым требовательным к ресурсам, тем более зависимым от заряда батареек. Да я уж лучше в lossy tak/flac тогда для телефонов сожму, с ~ 300 битрейтом и оно, что самое смешное, будет лучше любой lossy параши, которую вы тут обсуждаете из треда в тред, а дальше этой мейнстримной хуеты, конечно же, никто и не смотрел. Как и в случае топового (lossless) tak над ссаным (lossless) flac с очень уёбищными минусами потерь метаданных и прочим (у флака). Продолжайте жрать говно и выбирать менее вонючее, лол. У меня всё.
Тупой дегрель, желаю скорее кирпича твою телефончику. Опус был, есть и будет самым требовательным к ресурсам, тем более зависимым от заряда батареек. Да я уж лучше в lossy tak/flac тогда для телефонов сожму, с ~ 300 битрейтом и оно, что самое смешное, будет лучше любой lossy параши, которую вы тут обсуждаете из треда в тред, а дальше этой мейнстримной хуеты, конечно же, никто и не смотрел. Как и в случае топового (lossless) tak над ссаным (lossless) flac с очень уёбищными минусами потерь метаданных и прочим (у флака). Продолжайте жрать говно и выбирать менее вонючее, лол. У меня всё.
>>50830
У FLAC есть контейнер для тэгов Vorbis comment, есть ли такой у TAK? ТАК васянщина чистой воды. FLAC пилится нормальной организацией, которая явила миру ворбис и опус, а ещё FLAC начал своё повсеместное распространение, чего так никогда не получит. Сколько его плееров могут воспроизвести? Один?
> очень уёбищными минусами потерь метаданных и прочим (у флака)
У FLAC есть контейнер для тэгов Vorbis comment, есть ли такой у TAK? ТАК васянщина чистой воды. FLAC пилится нормальной организацией, которая явила миру ворбис и опус, а ещё FLAC начал своё повсеместное распространение, чего так никогда не получит. Сколько его плееров могут воспроизвести? Один?
>>50833
TAK пропретарщина, а этот достаточно когда куча свободных аналогов, даже Apple lossless, хоть эпл не выкладывает обновления исходного кода
TAK пропретарщина, а этот достаточно когда куча свободных аналогов, даже Apple lossless, хоть эпл не выкладывает обновления исходного кода
>>50838
Его автор вроде как хотел открыть.
Его автор вроде как хотел открыть.
>>50838
Согласен, пиписитарщина, но автор его из года в год ноется, что ему за столько лет надоело и хочет открывать, хз когда уже.
>>50833
Когда завезут нормальный искоробки режим подхвата всех метаданных у исходника, которые не будут обрезаться с упаковкой во flac и распаковкой обратно, не применяя при этом отдельный неудобный преф (который еще и не узнать, сжимался ли флак с этим префом или без). И когда будут нормальные скорость/размер максимального сжатия и молниеносная распковка в исходник - тогда и приходи, лол. По поводу первого минуса - вся соль в том, что васяны-релизеры, коих, блять, 99%, знать не знают про этот преф - итого вся музыка, кторая изначально была в диджитал исходниках - у них проёбана нещадно, ибо без него - оно уже не вернет тебе истинный размер исходника и комментарии. Иными словами, часть данных проёбется. Существенный минус. Что самое смешное - его учитывают все сторонние васянские лосслесс, искоропки поддерживая данные, даже вавпак, но только не флак. Нахуй и в пизду.
Согласен, пиписитарщина, но автор его из года в год ноется, что ему за столько лет надоело и хочет открывать, хз когда уже.
>>50833
Когда завезут нормальный искоробки режим подхвата всех метаданных у исходника, которые не будут обрезаться с упаковкой во flac и распаковкой обратно, не применяя при этом отдельный неудобный преф (который еще и не узнать, сжимался ли флак с этим префом или без). И когда будут нормальные скорость/размер максимального сжатия и молниеносная распковка в исходник - тогда и приходи, лол. По поводу первого минуса - вся соль в том, что васяны-релизеры, коих, блять, 99%, знать не знают про этот преф - итого вся музыка, кторая изначально была в диджитал исходниках - у них проёбана нещадно, ибо без него - оно уже не вернет тебе истинный размер исходника и комментарии. Иными словами, часть данных проёбется. Существенный минус. Что самое смешное - его учитывают все сторонние васянские лосслесс, искоропки поддерживая данные, даже вавпак, но только не флак. Нахуй и в пизду.
>>50850
Попробуй FLACCL что ли тогда.
> И когда будут нормальные скорость/размер максимального сжатия и молниеносная распковка в исходник - тогда и приходи, лол.
Попробуй FLACCL что ли тогда.
>>50833
Все относительно популярные. На основе ffmpeg его либо искоропки, либо плагином. На андроиде аналогично.
APEv2 уже у пориджей не котируется или чё? Честно говоря, мне теги никогда не были нужны, так что я даже не смотрел. Любой адекватный плеер умеет в filename и cover.jpg (пориджевую хуйню мелкобуквенную чтоб не чистить и не видеть какой-нибудь naturewave с сохранением оригинальных названий на японском, блять https://bandcamp.com/EmbeddedPlayer/album=3972823002/size=large/bgcol=ffffff/linkcol=333333/transparent=true/ ).
>Сколько его плееров могут воспроизвести? Один?
Все относительно популярные. На основе ffmpeg его либо искоропки, либо плагином. На андроиде аналогично.
>Vorbis comment, есть ли такой у TAK?
APEv2 уже у пориджей не котируется или чё? Честно говоря, мне теги никогда не были нужны, так что я даже не смотрел. Любой адекватный плеер умеет в filename и cover.jpg (пориджевую хуйню мелкобуквенную чтоб не чистить и не видеть какой-нибудь naturewave с сохранением оригинальных названий на японском, блять https://bandcamp.com/EmbeddedPlayer/album=3972823002/size=large/bgcol=ffffff/linkcol=333333/transparent=true/ ).
7 Кб, 694x113>>50868
Нет, там японский. По крайней мере, имя исполнителя. Может это просто кунъёми запись.
Нет, там японский. По крайней мере, имя исполнителя. Может это просто кунъёми запись.
>>50830
Кирпич от прослушиваемых кодеков, вот это реально - лол.
Ни разу не замечал за своим телефоном ни нехватки производительности, ни нехватки батареи.
Впрочем и музыку я почти не слушаю. Спустя время понял, что от прослушивания музыки на телефоне никаких положительных эмоций не получишь.
О какой потери данных ты говоришь? Если я возьму исходный флак, закодирую в mp3/opus/ogg/tak, и затем обратно во flac - потеряю часть метаданных?
Почему меня вообще должно это волновать, если все lossless файлы, которые можно взять из интернета, во flac - то есть там уже терять нечего? ape, wav и alac встречаются намного реже, tak я кажется ни разу не видел. А кодировать исходники во flac не нужно, так как есть более эффективные кодеки.
>желаю скорее кирпича твою телефончику
Кирпич от прослушиваемых кодеков, вот это реально - лол.
>Опус был, есть и будет самым требовательным к ресурсам, тем более зависимым от заряда батареек
Ни разу не замечал за своим телефоном ни нехватки производительности, ни нехватки батареи.
Впрочем и музыку я почти не слушаю. Спустя время понял, что от прослушивания музыки на телефоне никаких положительных эмоций не получишь.
>над ссаным (lossless) flac с очень уёбищными минусами потерь метаданных и прочим (у флака).
О какой потери данных ты говоришь? Если я возьму исходный флак, закодирую в mp3/opus/ogg/tak, и затем обратно во flac - потеряю часть метаданных?
Почему меня вообще должно это волновать, если все lossless файлы, которые можно взять из интернета, во flac - то есть там уже терять нечего? ape, wav и alac встречаются намного реже, tak я кажется ни разу не видел. А кодировать исходники во flac не нужно, так как есть более эффективные кодеки.
>>50837
Кажется, вместо паршивого звука, в кодированном файле звук стал ощутимо тише. С -filter:a "aresample=48000:resampler=soxr:precision=33" громкость была как в оригинале.
Которую используют гиганты Google и Apple, следственно развивают её.
>ты никогда не услышишь разницы, вот это манявнушение. В факе про это есть
Кажется, вместо паршивого звука, в кодированном файле звук стал ощутимо тише. С -filter:a "aresample=48000:resampler=soxr:precision=33" громкость была как в оригинале.
>этой мейнстримной хуеты
Которую используют гиганты Google и Apple, следственно развивают её.
>>50953
Нет. В исходнике (а исходник у flac - wav) может быть часть данных, комметарии и прочий довесок от исполнителя, которые довольно таки часто туда что-то пишут. Эти данные проебутся, когда ты этот wav упакуешь во flac и распакуешь, например, обратно, потому что нужна отдельная команда, которой никогда не было в дефолте. И распаковывать нужно тоже с этим параметром, иначе проебётся. А как я блять узнаю то есть/нет? Васяны посчитали что нинужно - значит нинужно. Нахуй и в пизду флак, в таком случае. Исходник должен быть исходником, то есть этичным, не тронутым (если я захочу flac обратно в wav перевести и не проебать часть байтов). Но ладно я, хорошо, теперь я это знаю и учитываю эту еблю, но как быть с дебичами, которые пакуют флаки и куда-нибудь вбрасывают? Ведь он так популярен. Соответственно - масштаб обосрамса у флак слишком очевиден над остальными lossless.
>>50852
Но оно только скорости прибавит, не размер сжатия же? Да и жирно слишком в сравнении, лол, когда так поддерживает любым некроговном и искоропки имеет несколько режимов оптимизаций под процы, от древнего говна мамонта mmx до современных, то есть в любых случаях работает быстро. Нахуй, это шах и мат над всеми lossless, ибо что еще нужно, если не размер сжатия с адекватной скоростью.
>О какой потери данных ты говоришь?
Нет. В исходнике (а исходник у flac - wav) может быть часть данных, комметарии и прочий довесок от исполнителя, которые довольно таки часто туда что-то пишут. Эти данные проебутся, когда ты этот wav упакуешь во flac и распакуешь, например, обратно, потому что нужна отдельная команда, которой никогда не было в дефолте. И распаковывать нужно тоже с этим параметром, иначе проебётся. А как я блять узнаю то есть/нет? Васяны посчитали что нинужно - значит нинужно. Нахуй и в пизду флак, в таком случае. Исходник должен быть исходником, то есть этичным, не тронутым (если я захочу flac обратно в wav перевести и не проебать часть байтов). Но ладно я, хорошо, теперь я это знаю и учитываю эту еблю, но как быть с дебичами, которые пакуют флаки и куда-нибудь вбрасывают? Ведь он так популярен. Соответственно - масштаб обосрамса у флак слишком очевиден над остальными lossless.
>>50852
Но оно только скорости прибавит, не размер сжатия же? Да и жирно слишком в сравнении, лол, когда так поддерживает любым некроговном и искоропки имеет несколько режимов оптимизаций под процы, от древнего говна мамонта mmx до современных, то есть в любых случаях работает быстро. Нахуй, это шах и мат над всеми lossless, ибо что еще нужно, если не размер сжатия с адекватной скоростью.
>>50969
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 ?
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 ?
Tak кодирует быстро. Удивидительно быстро. На пресете максимального сжатия -pMax размер файла меньше размера исходного flac (9.50 метров tak вместо 10.40 метров flac). Однако теги flac не сохраняются вообще, ни один из них.
53 Кб, 605x650>>51022
Несущественно. Сравните с FLACCL, который на OpenCL пожалуйста, там можно указать, сколько ядер использовать при кодировании, да и вообще всё продвинуто, как я посмотрел.
> 9.50 метров tak вместо 10.40 метров flac
Несущественно. Сравните с FLACCL, который на OpenCL пожалуйста, там можно указать, сколько ядер использовать при кодировании, да и вообще всё продвинуто, как я посмотрел.
428 Кб, 1182x912>>50991
Скорее всего он о джиттер-коррекции. Мегабородатом меме из мира аудиофилов начала 00-х.
>На CD разве есть комментарии, да вообще хоть какие-то теги?
Скорее всего он о джиттер-коррекции. Мегабородатом меме из мира аудиофилов начала 00-х.
>>50991
Не, ты уж извини, конечно, но это вчерашний день. В эпоху интернета стал популярен не CD, а диджитал, его еще WEB отмечают. Понятное дело, что мейнстримную часть музыки это не так сильно коснулось, но кто угорел по сервисам и прочим стриминговым площадкам с поддержкой lossless и pcm (в том числе приобретение), где музыканты заводят себе авторские страницы и выкладывают контент в первозданном виде без третьих лиц/без перекодирования (а то и вовсе без лейблов) - это имеет место быть, именно в таких случаях и могут попадаться авторские метаданные. А вообще, оригинало/md5 шизы меня должны понять, почему это так важно не проебать.
Это не совсем является исходником, тебе упаковали просто. Исходное в WAV/AIF/AIFF.
Градация у дисков такая: Есть исходное wav/aif/aiff от музыканта -> этот wav передаётся звуковику, который сводит и убирает все кривости -> потом это отдаётся обратно автору -> автор передаёт полученный мастеринг на лейбл, при необходимости там тоже могут что-то править/подрезать/делать всякие radio edit/extended/etc -> далее с лейбла передают это сторонним васянам, которые клепают CD/кассеты, либо лейбл их делает сам, то есть без третьих лиц -> потом уже пираты рипуют диск сразу же во flac, для экономии места.
А у диджитал всё тоже самое, кроме последних двух -> после этого либо лейбл публикует его как диджитал релиз, либо автор вообще без лейблов его выпускает (а то и вовсе без мастеринга, не суть).
Итого мы покупаем этот диджитал в исходном/авторском формате и видим там различные записи в метаданных, а чтоб их не проебать и упаковать с ними в lossless (flac/tak/alac/wavpack) для экономии места и если надо - то и распаковать обратно и чтоб файл не проебал часть байтов - флаку нужен отдельный преф, остальным - не нужно, всё искоропки. И вот васяны, кто релизит и вбрасывает - не знают об этом - в результате у некоторых коллекционеров музла горит (и не от васянов, а скорее от долбоебизма флака с очень очевидным минусом).
Бля, сколько можно разжевывать, лол.
Не всегда, на самом деле. И это только у тех форматов, которые поддерживают теги, а wav официально не поддерживает (у адекватного музыканта исходник всегда без потерь, то есть wav/aif/aiff (pcm) не суть). И учитывая что тегов в wav нет и делается это любым кустарным методом, то там нет заголовков и прочего - комментарии в таком случае всего лишь условны и могут быть расположены где, как угодно и любым методом. А вообще, Bandcamp на самом деле, хоть и сасный, но бляяять, они поощряют транскод, который никак не узнаешь, кроме как параноиком в спектры каждой скачки/покупки заглядывать, да-да. Короче, не идеальный он, но все пердят и пользуются.
>>51022
Честно говоря, я последний раз тестами занимался года два назад, точно не припомню где он больше всего прироста давал с -p4m и максимальным flac (какой там, забыл уже, -8?). То ли в эмбиент музыке, то ли в прочих вещах где много статичного монохрома типо того же эмбиент-хауса/лоуфай хауса/дип/etc. А у бодрой электроники разница будет не так сильно заметна. Помню что некоторые релизы https://truthradio.bandcamp.com/music сильно отличались в размере (скачанные wav 16/24бит кодируя в максимальные прессеты tak и flac), была разница от 1 до 4 мб, может и больше, я забыл уже всё.
У Tak другие теги - APEv2. Нужна мокропися, наверное, чтоб вмержить их автоматически. Бгг эти ссаные теги, возня мух извечная. Официальная тулза Tak вообще только wav должна поддерживать для конвертации в Tak, а раз их там нет, то
Не, ты уж извини, конечно, но это вчерашний день. В эпоху интернета стал популярен не 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 на самом деле, хоть и сасный, но бляяять, они поощряют транскод, который никак не узнаешь, кроме как параноиком в спектры каждой скачки/покупки заглядывать, да-да. Короче, не идеальный он, но все пердят и пользуются.
>>51022
Честно говоря, я последний раз тестами занимался года два назад, точно не припомню где он больше всего прироста давал с -p4m и максимальным flac (какой там, забыл уже, -8?). То ли в эмбиент музыке, то ли в прочих вещах где много статичного монохрома типо того же эмбиент-хауса/лоуфай хауса/дип/etc. А у бодрой электроники разница будет не так сильно заметна. Помню что некоторые релизы https://truthradio.bandcamp.com/music сильно отличались в размере (скачанные wav 16/24бит кодируя в максимальные прессеты tak и flac), была разница от 1 до 4 мб, может и больше, я забыл уже всё.
>Однако теги flac не сохраняются вообще, ни один из них
У Tak другие теги - APEv2. Нужна мокропися, наверное, чтоб вмержить их автоматически. Бгг эти ссаные теги, возня мух извечная. Официальная тулза Tak вообще только wav должна поддерживать для конвертации в Tak, а раз их там нет, то
>>50991
Не, ты уж извини, конечно, но это вчерашний день. В эпоху интернета стал популярен не CD, а диджитал, его еще WEB отмечают. Понятное дело, что мейнстримную часть музыки это не так сильно коснулось, но кто угорел по сервисам и прочим стриминговым площадкам с поддержкой lossless и pcm (в том числе приобретение), где музыканты заводят себе авторские страницы и выкладывают контент в первозданном виде без третьих лиц/без перекодирования (а то и вовсе без лейблов) - это имеет место быть, именно в таких случаях и могут попадаться авторские метаданные. А вообще, оригинало/md5 шизы меня должны понять, почему это так важно не проебать.
Это не совсем является исходником, тебе упаковали просто. Исходное в WAV/AIF/AIFF.
Градация у дисков такая: Есть исходное wav/aif/aiff от музыканта -> этот wav передаётся звуковику, который сводит и убирает все кривости -> потом это отдаётся обратно автору -> автор передаёт полученный мастеринг на лейбл, при необходимости там тоже могут что-то править/подрезать/делать всякие radio edit/extended/etc -> далее с лейбла передают это сторонним васянам, которые клепают CD/кассеты, либо лейбл их делает сам, то есть без третьих лиц -> потом уже пираты рипуют диск сразу же во flac, для экономии места.
А у диджитал всё тоже самое, кроме последних двух -> после этого либо лейбл публикует его как диджитал релиз, либо автор вообще без лейблов его выпускает (а то и вовсе без мастеринга, не суть).
Итого мы покупаем этот диджитал в исходном/авторском формате и видим там различные записи в метаданных, а чтоб их не проебать и упаковать с ними в lossless (flac/tak/alac/wavpack) для экономии места и если надо - то и распаковать обратно и чтоб файл не проебал часть байтов - флаку нужен отдельный преф, остальным - не нужно, всё искоропки. И вот васяны, кто релизит и вбрасывает - не знают об этом - в результате у некоторых коллекционеров музла горит (и не от васянов, а скорее от долбоебизма флака с очень очевидным минусом).
Бля, сколько можно разжевывать, лол.
Не всегда, на самом деле. И это только у тех форматов, которые поддерживают теги, а wav официально не поддерживает (у адекватного музыканта исходник всегда без потерь, то есть wav/aif/aiff (pcm) не суть). И учитывая что тегов в wav нет и делается это любым кустарным методом, то там нет заголовков и прочего - комментарии в таком случае всего лишь условны и могут быть расположены где, как угодно и любым методом. А вообще, Bandcamp на самом деле, хоть и сасный, но бляяять, они поощряют транскод, который никак не узнаешь, кроме как параноиком в спектры каждой скачки/покупки заглядывать, да-да. Короче, не идеальный он, но все пердят и пользуются.
>>51022
Честно говоря, я последний раз тестами занимался года два назад, точно не припомню где он больше всего прироста давал с -p4m и максимальным flac (какой там, забыл уже, -8?). То ли в эмбиент музыке, то ли в прочих вещах где много статичного монохрома типо того же эмбиент-хауса/лоуфай хауса/дип/etc. А у бодрой электроники разница будет не так сильно заметна. Помню что некоторые релизы https://truthradio.bandcamp.com/music сильно отличались в размере (скачанные wav 16/24бит кодируя в максимальные прессеты tak и flac), была разница от 1 до 4 мб, может и больше, я забыл уже всё.
У Tak другие теги - APEv2. Нужна мокропися, наверное, чтоб вмержить их автоматически. Бгг эти ссаные теги, возня мух извечная. Официальная тулза Tak вообще только wav должна поддерживать для конвертации в Tak, а раз их там нет, то
Не, ты уж извини, конечно, но это вчерашний день. В эпоху интернета стал популярен не 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 на самом деле, хоть и сасный, но бляяять, они поощряют транскод, который никак не узнаешь, кроме как параноиком в спектры каждой скачки/покупки заглядывать, да-да. Короче, не идеальный он, но все пердят и пользуются.
>>51022
Честно говоря, я последний раз тестами занимался года два назад, точно не припомню где он больше всего прироста давал с -p4m и максимальным flac (какой там, забыл уже, -8?). То ли в эмбиент музыке, то ли в прочих вещах где много статичного монохрома типо того же эмбиент-хауса/лоуфай хауса/дип/etc. А у бодрой электроники разница будет не так сильно заметна. Помню что некоторые релизы https://truthradio.bandcamp.com/music сильно отличались в размере (скачанные wav 16/24бит кодируя в максимальные прессеты tak и flac), была разница от 1 до 4 мб, может и больше, я забыл уже всё.
>Однако теги flac не сохраняются вообще, ни один из них
У Tak другие теги - APEv2. Нужна мокропися, наверное, чтоб вмержить их автоматически. Бгг эти ссаные теги, возня мух извечная. Официальная тулза Tak вообще только wav должна поддерживать для конвертации в Tak, а раз их там нет, то
>>51062
то будут только те что были.
то будут только те что были.
Пожал альбом из flac (не знаю, с какими настройками он был сжат) в 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) компьютер изрядно лагал, кстати.
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) компьютер изрядно лагал, кстати.
>>51062
Процентов 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%, отказываясь от тегов и засирая диск временными файлами - хуйня а не идея.
>Не, ты уж извини, конечно, но это вчерашний день. В эпоху интернета стал популярен не 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%, отказываясь от тегов и засирая диск временными файлами - хуйня а не идея.
>>51062
Процентов 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%, отказываясь от тегов и засирая диск временными файлами - хуйня а не идея.
>Не, ты уж извини, конечно, но это вчерашний день. В эпоху интернета стал популярен не 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%, отказываясь от тегов и засирая диск временными файлами - хуйня а не идея.
>>51147
Не отказываясь от тегов*
Совсем уже запутался в этом пердолинге.
11% - цифра немаленькая, но из-за кучи временных файлов процесс кодирования может растянуться надолго.
>отказываясь от тегов и засирая диск временными файлами
Не отказываясь от тегов*
Совсем уже запутался в этом пердолинге.
11% - цифра немаленькая, но из-за кучи временных файлов процесс кодирования может растянуться надолго.
Ебись конём, автор TAK. Какого хуя у меня через Mp3tag перенеслось только 4 ёбаных тега (album, artist, comment, title), когда в исходном flac файле тегов было 20+? Этой хуйнёй элементарно нельзя пользоваться - как можно серьёзно слушать музыку без тегов? А если хочешь слушать музыку несерьёзно, то добро пожаловать на онлайн-радио, зайцев.нет и mp3@96kbps.
>>51217
Да объяснили же тебе, у flac совсем другие теги и вот вам еще один ёбаный обосрамс, вместо того чтоб пилить совместимые универсальные - васяны просто плодят хуергу из пустого в порожнее. Это не проблема TAK вообще, а APEv2 и того, откуда ты пиздишь теги. Бери изначально музло с apev2 тегами, либо пиши вручную фубаром, он хоть в пакетное редактирование может.
Ты так интересно это говоришь, словно 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. Ладно уж, сказал, всё равно ж никто не станет эти безызвестные вещи пробовать.
Да объяснили же тебе, у 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. Ладно уж, сказал, всё равно ж никто не станет эти безызвестные вещи пробовать.
>>51250
Opus и FLAC уже давно нет, их даже в браузеры по умолчанию добавили, а все видео на YT вообще в опусе в качестве звуковой дорожки.
> Так такая же экзотика
Opus и FLAC уже давно нет, их даже в браузеры по умолчанию добавили, а все видео на YT вообще в опусе в качестве звуковой дорожки.
>>51250
Как раз-таки у флака, опуса и ворбис стандартизированные теги, называется это чудо Vorbis Comments и отлично задокументировано.
> васяны просто плодят хуергу из пустого в порожнее
Как раз-таки у флака, опуса и ворбис стандартизированные теги, называется это чудо Vorbis Comments и отлично задокументировано.
>>51253
Да, но что-то как дело касается переноса тегов - так сразу пук среньк писикак, ниработает.
Да, но что-то как дело касается переноса тегов - так сразу пук среньк писикак, ниработает.
>>51252
А у нас ютуб в качестве сервиса онлайн видео подразумевается людьми? Кому из так называемых обычных людей вообще известно какой там формат-то, блять. Раз уж спиздели про боычных, то обычные как жали свой калич в v0 mp3 и avc/avi, так и будут это делать еще ближайшие лет 50, лол. Не стоит мешать мух с котлетами. Разве я не прав? Что сейчас мейнстрим в 2к22 на раздачах в lossy - конечно же пиздоглазый мертвый mp3, был есть и будет, куда уж там, opus, ага.
А у нас ютуб в качестве сервиса онлайн видео подразумевается людьми? Кому из так называемых обычных людей вообще известно какой там формат-то, блять. Раз уж спиздели про боычных, то обычные как жали свой калич в v0 mp3 и avc/avi, так и будут это делать еще ближайшие лет 50, лол. Не стоит мешать мух с котлетами. Разве я не прав? Что сейчас мейнстрим в 2к22 на раздачах в lossy - конечно же пиздоглазый мертвый mp3, был есть и будет, куда уж там, opus, ага.
>>51255
>>51217
На самом деле работает, в тот раз я, видимо, неправильно переносил. Что вообще может быть сложного в копировании текста из файла в файл в 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()
Такой же на импорт, но без лишнего в начале и в конце.
>>51250
Звучит, как чёрная магия.
Практично - не нужно лишний раз перекодировать, когда нужен lossy. Закончилось место на диске - удалил lossless-файл, lossy-файл остался - проблема решена.
Как опробовать эту фичу?
>>51217
На самом деле работает, в тот раз я, видимо, неправильно переносил. Что вообще может быть сложного в копировании текста из файла в файл в 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()
Такой же на импорт, но без лишнего в начале и в конце.
>>51250
>А вот комбинирующий режим - в эти 15мб уместит и lossless и lossy - двумя файлами. lossy вариант не будет требовать втрого файла и будет играть как есть, а вот lossless файл будет требовать рядом с ним еще и lossy файл
Звучит, как чёрная магия.
Практично - не нужно лишний раз перекодировать, когда нужен lossy. Закончилось место на диске - удалил lossless-файл, lossy-файл остался - проблема решена.
Как опробовать эту фичу?
>>51217
Ебать дебил, ты музыка слушаешь или теги читаешь? Вообще похуй, название файла достаточно, есть имя и название композиции. Главное что музыка без сжатия и всё
Ебать дебил, ты музыка слушаешь или теги читаешь? Вообще похуй, название файла достаточно, есть имя и название композиции. Главное что музыка без сжатия и всё
Какой самый медленный качественный метод масштабирования? Ланцош? Какой применяется по умолчанию? Какой командой его изменить?
>>51544
Двачую вопрос.
Двачую вопрос.
>>51544
Для уменьшения - супервыборка. Для увеличения - бикубический.
>Какой самый качественный метод масштабирования?
Для уменьшения - супервыборка. Для увеличения - бикубический.
1,7 Мб, mp4,720x480, 0:04
>>51701
Тогда помянем. Используй тупо lanczos и не парься. Либо пердоль через avisynth/vapoursynth, там полно разной чепухи.
Если ты заранее уменьшаешь, через топаз, тогда зачем тебе скейлить еще через ffmpeg?
>У меня Radeon.
Тогда помянем. Используй тупо lanczos и не парься. Либо пердоль через avisynth/vapoursynth, там полно разной чепухи.
>Я уменьшу с UltraHD до FullHD после топаза, как в ffmpeg прописать супервыборку?
Если ты заранее уменьшаешь, через топаз, тогда зачем тебе скейлить еще через ffmpeg?
>>51732
Я не уменьшаю заранее..
Я не уменьшаю заранее..
>>51062
По моему там одним единственным wav файлом не обойтись. Там по идее должен быть файл проекта, с расставленными по времени семплами, готовыми лупами, и прочимим эффектами.
А уже сведённое аудио врятли можно пофиксить.
> Есть исходное wav/aif/aiff от музыканта -> этот wav передаётся звуковику, который сводит и убирает все кривости
По моему там одним единственным wav файлом не обойтись. Там по идее должен быть файл проекта, с расставленными по времени семплами, готовыми лупами, и прочимим эффектами.
А уже сведённое аудио врятли можно пофиксить.
>>44406 (OP)
В каком кодеке хранят видео платные онлайн-кинотеатры (ivi, netflix и другие)? H265 в браузерах нет.
Где вообще используется h265?
В каком кодеке хранят видео платные онлайн-кинотеатры (ivi, netflix и другие)? H265 в браузерах нет.
Где вообще используется h265?
>>52095
BluRay, стриминг в мобильные приложения, … В общем везде, где аппаратное декодирование важнее проблем с лицензированием кодека.
> Где вообще используется h265?
BluRay, стриминг в мобильные приложения, … В общем везде, где аппаратное декодирование важнее проблем с лицензированием кодека.
Есть какие-то хинты по сжатию изначально дико пережатого (с потерями) видео с crf? Скачал с твитера видео, захотел сжать и получилось видео в 2 раза тяжелее оригинала. Алгоритм, видимо, сильно пытается передать все нюансы артефактов сжатия.
>>54414
Это тоже самое, что снижать разрешение. А вообще ему деблокер нужен. А поскольку деблокер в декодере очевидно не справляется, то тут могут помочь только искусственные нейронные сети.
> Можешь попробовать добавить blur
Это тоже самое, что снижать разрешение. А вообще ему деблокер нужен. А поскольку деблокер в декодере очевидно не справляется, то тут могут помочь только искусственные нейронные сети.
>>54794
>>54414
Да мне не качество надо исправить, а просто ужать ещё немного. А кодировщик вместо этого усирается, пытаясь идеально сохранить все артефакты оригинального видео и выходит худшее качество при большем объёме. Конечно, самое простое решение это посмотреть какой битрейт в оригинальном видео и кодировать с VBT пониже или под нужный размер. Но я хочу crf.
>>54414
Да мне не качество надо исправить, а просто ужать ещё немного. А кодировщик вместо этого усирается, пытаясь идеально сохранить все артефакты оригинального видео и выходит худшее качество при большем объёме. Конечно, самое простое решение это посмотреть какой битрейт в оригинальном видео и кодировать с VBT пониже или под нужный размер. Но я хочу crf.
>>54825
Твоё видео наверняка кодировалось под битрейт (не исключено что постоянный), а ты тут с crf мучаешься.
Твоё видео наверняка кодировалось под битрейт (не исключено что постоянный), а ты тут с crf мучаешься.
154 Кб, 488x2000>>54825
Ну ставь тогда CRF повыше и жми сильнее, кто ж мешает? Но если даже CRFом выходит худшее качество при большем объёме, то уже ничегос этим не поделаешь. Попробуй пресет помедленее. Попробуй 2 прохода, если жмёшь в VP9. Попробуй кодек поэффективнее.
>>54794
Нейронки пока глупенькие, у самого топаз сейчас на фоне пыхтит. Ими есть смысл именно улучшать изначально неплохое качество, а не пытаться восстановить шакалы твиттера, как в случае анона. Попробовать можно, но очень сомневаюсь, что в этом будет толк. Хотя мы не видели сабж, может там всё не так плохо.
Ну ставь тогда CRF повыше и жми сильнее, кто ж мешает? Но если даже CRFом выходит худшее качество при большем объёме, то уже ничегос этим не поделаешь. Попробуй пресет помедленее. Попробуй 2 прохода, если жмёшь в VP9. Попробуй кодек поэффективнее.
>>54794
Нейронки пока глупенькие, у самого топаз сейчас на фоне пыхтит. Ими есть смысл именно улучшать изначально неплохое качество, а не пытаться восстановить шакалы твиттера, как в случае анона. Попробовать можно, но очень сомневаюсь, что в этом будет толк. Хотя мы не видели сабж, может там всё не так плохо.
>>54855
Да это понятно. Я просто надеялся на хинты какие-то, тайные знания, чтобы не ебаться с перебором.
>Ну ставь тогда CRF повыше и жми сильнее, кто ж мешает?
Да это понятно. Я просто надеялся на хинты какие-то, тайные знания, чтобы не ебаться с перебором.
>>44406 (OP)
Аноны, а есть какие-нибудь апскейлеры видео для высоких разрешений? Интересует 4К -> 8К/12К. Хочется качество получше обычного ланкоша, но в то же время толстые нейросети типа Топаза или ESRGAN не подходят из-за производительности. Пытался нагуглить использование быстрых реалтайм апскейлеров типа RAVU, но нихуя не гуглится в связке с энкодером, только анимешный вайфу2х нашёл. Это вообще выполнимая задача или в любом случае я буду часовой видос конвертить сутки в 12К?
Аноны, а есть какие-нибудь апскейлеры видео для высоких разрешений? Интересует 4К -> 8К/12К. Хочется качество получше обычного ланкоша, но в то же время толстые нейросети типа Топаза или ESRGAN не подходят из-за производительности. Пытался нагуглить использование быстрых реалтайм апскейлеров типа RAVU, но нихуя не гуглится в связке с энкодером, только анимешный вайфу2х нашёл. Это вообще выполнимая задача или в любом случае я буду часовой видос конвертить сутки в 12К?
>>55569
а нет нахой таких, чтобы быстро. Любая нейросетка будет долго работать. Да и зачем такие апскейлы вообще нужны, тысячу лет будешь их рендерить. Попробуй посмотреть VSGAN.
И непонятно тебе для чего? Видео в реалтайме смотреть или что?
Еще есть Red Giant Shooter Instant 4K и только в старых версиях, но не знаю есть ли там 12к, да даже 8к.
а нет нахой таких, чтобы быстро. Любая нейросетка будет долго работать. Да и зачем такие апскейлы вообще нужны, тысячу лет будешь их рендерить. Попробуй посмотреть VSGAN.
И непонятно тебе для чего? Видео в реалтайме смотреть или что?
Еще есть Red Giant Shooter Instant 4K и только в старых версиях, но не знаю есть ли там 12к, да даже 8к.
>>55757
Но ведь в MPV есть NNEDI3 и RAVU, которые работают в реалтайме и могут как раз то что я хочу. Да хотя бы амдэшный FSR, всё лучше ланкоша.
360-видео апскейлить. Когда полусфера в 2К/4К, кроп в 60 градусов выглядит как 720р-пиздец с бикубиком.
> а нет нахой таких, чтобы быстро
Но ведь в MPV есть NNEDI3 и RAVU, которые работают в реалтайме и могут как раз то что я хочу. Да хотя бы амдэшный FSR, всё лучше ланкоша.
> И непонятно тебе для чего?
360-видео апскейлить. Когда полусфера в 2К/4К, кроп в 60 градусов выглядит как 720р-пиздец с бикубиком.
>>55773
Я думал, это дэинтерлейсер скрипт для avisynth нет?
первый раз слышу о таком.
явно давно запилили фигню какую-нибудь на нем, по типу magpie. Он же опенсорс.
А, тогда понятно, есть причины.
>NNEDI3
Я думал, это дэинтерлейсер скрипт для avisynth нет?
>RAVU
первый раз слышу о таком.
>Да хотя бы амдэшный FSR
явно давно запилили фигню какую-нибудь на нем, по типу magpie. Он же опенсорс.
>360-видео апскейлить. Когда полусфера в 2К/4К, кроп в 60 градусов выглядит как 720р-пиздец с бикубиком.
А, тогда понятно, есть причины.
>>55785
Ну вот я нихуя не нагуглил. В ffmpeg есть поддержка CUDA, но там максимум что реализовали - аппаратный ланкош...
Как шейдером обработать видео я не нашел, вангую через avisynth что-то можно, но чувствую там пердолинг неимоверный будет.
> явно давно запилили фигню какую-нибудь на нем, по типу magpie
Ну вот я нихуя не нагуглил. В ffmpeg есть поддержка CUDA, но там максимум что реализовали - аппаратный ланкош...
Как шейдером обработать видео я не нашел, вангую через avisynth что-то можно, но чувствую там пердолинг неимоверный будет.
>>55796
Supersampling же еще есть.
Забыл кстати. Юзай hybrid от selur. Там куча говна с апскейлами через avisynth/vapoursynth. Но чтобы получить сборку с VSGAN как раз, про который говорил, надо писать разрабу, потому что весит дохрена.
Да и вообще через него кодировать приятно. Тыкаешь галочки и скрипт сам пишется, можно посмотреть в последнем окне. FFMPEG тоже конечно умеет через ави и вапор работать, но сам скрипт придется самому писать.
>В ffmpeg есть поддержка CUDA, но там максимум что реализовали - аппаратный ланкош...
Supersampling же еще есть.
>вангую через avisynth что-то можно
Забыл кстати. Юзай hybrid от selur. Там куча говна с апскейлами через avisynth/vapoursynth. Но чтобы получить сборку с VSGAN как раз, про который говорил, надо писать разрабу, потому что весит дохрена.
Да и вообще через него кодировать приятно. Тыкаешь галочки и скрипт сам пишется, можно посмотреть в последнем окне. FFMPEG тоже конечно умеет через ави и вапор работать, но сам скрипт придется самому писать.
>>55867
Вот это то что я и хотел, благодарю. Но желаемого результата я всё равно не получил. Самое лучше что получилось - шарп aWArp + дехало + ланкош. 4К -> 8К в 10 фпс конвертит. А все быстрые нейросетки не справляются с моим мылом, хуже чем шарп + дехало выдают картинку. Топаз хорош, но там 2 секунды на кадр...
>>55867
Не ебёт, мне ланкош нравится больше.
> hybrid от selur
Вот это то что я и хотел, благодарю. Но желаемого результата я всё равно не получил. Самое лучше что получилось - шарп aWArp + дехало + ланкош. 4К -> 8К в 10 фпс конвертит. А все быстрые нейросетки не справляются с моим мылом, хуже чем шарп + дехало выдают картинку. Топаз хорош, но там 2 секунды на кадр...
>>55867
Не ебёт, мне ланкош нравится больше.
![Before.I.Disappear.2014.1080p.AMZN.WEB-DL.DDP5.1.x264-NTb.m[...].png](https://2ch.life//s/src/3144406/16536569652461.png)
>>56061
Ну тут уж ты много хочешь... 10 фпс отличный результат как по мне. Для реалтайма надо искать какие-нибудь шейдеры для плеера glsl по типу anime4k. Но ESRGAN конечно вообще конкурентов нет. Долго фиксили и тренировали, еще и самому можно тренировать.
Это еще быстро. Я в 6 секунд кодирую. Знаю чувака, который купил 4 штуки 3090 на выходе ее, чтобы целые фильмы по 2-2.5 часа кодировать и апскйелить быстро. На что только люди не пойдут для дрочки на качество.
Я тоже однажды один видосик на 1:30 минуты конвертил месяц. без пизды. И еще признаюсь, сам фильм конвертил еще на старых версиях, уже тогда был слишком офигенный результат. Особенно для реальных людей, прямо все волосы, все реснички идеально дорисовываются как настоящие, как будто через ультрачеткую линзу фотоаппарата смотришь.
>Самое лучше что получилось - шарп aWArp + дехало + ланкош. 4К -> 8К в 10 фпс конвертит.
Ну тут уж ты много хочешь... 10 фпс отличный результат как по мне. Для реалтайма надо искать какие-нибудь шейдеры для плеера glsl по типу anime4k. Но ESRGAN конечно вообще конкурентов нет. Долго фиксили и тренировали, еще и самому можно тренировать.
>Топаз хорош, но там 2 секунды на кадр...
Это еще быстро. Я в 6 секунд кодирую. Знаю чувака, который купил 4 штуки 3090 на выходе ее, чтобы целые фильмы по 2-2.5 часа кодировать и апскйелить быстро. На что только люди не пойдут для дрочки на качество.
Я тоже однажды один видосик на 1:30 минуты конвертил месяц. без пизды. И еще признаюсь, сам фильм конвертил еще на старых версиях, уже тогда был слишком офигенный результат. Особенно для реальных людей, прямо все волосы, все реснички идеально дорисовываются как настоящие, как будто через ультрачеткую линзу фотоаппарата смотришь.
>>56084
Я тоже пробовал его обучать и тоже не мог побороть замыливание текстур. Обычный ESRGAN страдает овершарпом, а в Real как на твоём первом пике - забор полностью уничтожен, так и у меня часто бывало фоны просто нахуй удаляло, потому что у меня датасет со скудными фонами или вообще без них. А ведь если начну фонов больше делать, то он начнёт обучаться тому что мне не надо.
> Real-ESRGAN
Я тоже пробовал его обучать и тоже не мог побороть замыливание текстур. Обычный ESRGAN страдает овершарпом, а в Real как на твоём первом пике - забор полностью уничтожен, так и у меня часто бывало фоны просто нахуй удаляло, потому что у меня датасет со скудными фонами или вообще без них. А ведь если начну фонов больше делать, то он начнёт обучаться тому что мне не надо.
>>56117
Ну так специально показали, чтобы знали что он агрессивный. Все-таки частицы мелкие прям.
>а в Real как на твоём первом пике - забор полностью уничтожен
Ну так специально показали, чтобы знали что он агрессивный. Все-таки частицы мелкие прям.
64 Кб, 720x720>>56084
> Но ESRGAN конечно вообще конкурентов нет
> проёбана сеть, по лестницам можно спустится в ад, с глазами в одной руке, потому что для просмотра подобного они не нужны
>>56084
Читал другого, который купил две 3090, но из-за глюков оборудования(у части пользователей программы вылетает в разные промежутки времени, у этого вылетает моментально) не может ничего апскейлить.
> Знаю чувака, который купил 4 штуки 3090 на выходе ее, чтобы целые фильмы по 2-2.5 часа кодировать и апскйелить быстро
Читал другого, который купил две 3090, но из-за глюков оборудования(у части пользователей программы вылетает в разные промежутки времени, у этого вылетает моментально) не может ничего апскейлить.
>>44406 (OP)
Есть ли большой гайд по кодекам со сравнениями, скриншотами и т.д.
Есть ли большой гайд по кодекам со сравнениями, скриншотами и т.д.
>>56725
хорошая шутка
пипитарный ж
Но у тебя ав1 лучший из лучших!
Белены объелся?
>Av1 лучший из лучших
хорошая шутка
>h265 нормальный
пипитарный ж
>vp9 медленное говно
Но у тебя ав1 лучший из лучших!
>h264 средний
>средний
Белены объелся?
>>58045
В том и дело что svt-av1 за одинаковое время выдаст файл выглядий лучше, чем vp9 (libvpx)
Да, средний, картинка начинает разваливаться в пиксельную кашу
В том и дело что svt-av1 за одинаковое время выдаст файл выглядий лучше, чем vp9 (libvpx)
Да, средний, картинка начинает разваливаться в пиксельную кашу
Не знаю, в этот тред или мб в какой-нибудь тред в /mov/ про пиратство, но энивей:
Почему видеорелизы в 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). В описании такого релиза есть умные слова, типа:
А в результате картинка отличается от релиза этого же самого фильма, но официального 1080p SDR от самой студии. Другие оттенки (больше всего заметно на красном) + немного потусклее + чуть-чуть более синее. Пикрил - один и тот же кадр из ремукса официального блюрея 1080p и из конверта HDR->SDR из блюрея 4K. Откройте в разных вкладках и пощёлкайте туда-сюда для наглядности.
В общем, какие технические препятствия мешают "однозначно" переводить HDR в SDR, пусть и с лосси потерей передачи наиболее насыщенных цветов и тонкостей полутонов? Почему оно ВОТ ТАК?
Почему видеорелизы в 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, пусть и с лосси потерей передачи наиболее насыщенных цветов и тонкостей полутонов? Почему оно ВОТ ТАК?
Не знаю, в этот тред или мб в какой-нибудь тред в /mov/ про пиратство, но энивей:
Почему видеорелизы в 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). В описании такого релиза есть умные слова, типа:
А в результате картинка отличается от релиза этого же самого фильма, но официального 1080p SDR от самой студии. Другие оттенки (больше всего заметно на красном) + немного потусклее + чуть-чуть более синее. Пикрил - один и тот же кадр из ремукса официального блюрея 1080p и из конверта HDR->SDR из блюрея 4K. Откройте в разных вкладках и пощёлкайте туда-сюда для наглядности.
В общем, какие технические препятствия мешают "однозначно" переводить HDR в SDR, пусть и с лосси потерей передачи наиболее насыщенных цветов и тонкостей полутонов? Почему оно ВОТ ТАК?
Почему видеорелизы в 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, пусть и с лосси потерей передачи наиболее насыщенных цветов и тонкостей полутонов? Почему оно ВОТ ТАК?
340 Кб, 640x730>>58188
Почему нельзя? Можно, тогда ты получаешь
Ты же звуковик, была у меня как-то проблема перевести 5 или 7 к 1 в стерео и я знатно заебался, потому что простым конвертом получал еботерию в итоге поебавшись с кучей фильтров и не осилив задачу(конечно я бы смог, просто не захотел, утешаю себя я) пришлось скачать уже релиз в стерео и перемуксить звук. А всего то ебать, надо было все слить в 2 канала из 7, говно вопрос же
> А почему т.н. "HDR" картинку нельзя просто и однозначно превратить в "SDR"? Почему нельзя просто обрезать наиболее светлые и наиболее черные значения диапазона, которые выходят за рамки диапазона SDR, и уменьшить битность представления тех цветов/оттенков, которые таки входят в диапазон SDR, и получить ту же самую картинку, просто лишенную этой дополнительной точности?
Почему нельзя? Можно, тогда ты получаешь
> Вот у меня видеокарта(?) и монитор(?) не умеют в HDR, и поэтому 4K-блюреи (которые почти все поголовно в HDR) выглядят серыми и блёклыми
Ты же звуковик, была у меня как-то проблема перевести 5 или 7 к 1 в стерео и я знатно заебался, потому что простым конвертом получал еботерию в итоге поебавшись с кучей фильтров и не осилив задачу(конечно я бы смог, просто не захотел, утешаю себя я) пришлось скачать уже релиз в стерео и перемуксить звук. А всего то ебать, надо было все слить в 2 канала из 7, говно вопрос же
>>58190
Смотря что за "еботерию". Вообще в стерео (обычные 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.
>потому что простым конвертом получал еботерию
Смотря что за "еботерию". Вообще в стерео (обычные 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.
>>58192
Ну внутрянок хдра я не знаю, никогда даже релизов таких не пробовал, хотя у меня и карта и монитор и кабель и даже виндевс поддерживает хдр, так что не смогу тебе пояснить как всё реально устроено и какими формулами нужно приводить цвета в сдр. Очевидно одно, подход в лоб не работает.
Ну внутрянок хдра я не знаю, никогда даже релизов таких не пробовал, хотя у меня и карта и монитор и кабель и даже виндевс поддерживает хдр, так что не смогу тебе пояснить как всё реально устроено и какими формулами нужно приводить цвета в сдр. Очевидно одно, подход в лоб не работает.
>>58195
Вот те два скрина в пнг у тебя на таком сетапе выглядят по-разному, верно? На одном красный цвет в купальниках более малиновый, на другом более оранжевый, + очень легкая синеватая дымка поверх всего?
>хотя у меня и карта и монитор и кабель и даже виндевс поддерживает хдр
Вот те два скрина в пнг у тебя на таком сетапе выглядят по-разному, верно? На одном красный цвет в купальниках более малиновый, на другом более оранжевый, + очень легкая синеватая дымка поверх всего?
>>58188
Из конвертера картинка лучше. Чуть тусклее, но зато больше деталей видно. В ремуксе детали либо недосвечены, либо пересвечены.
Из конвертера картинка лучше. Чуть тусклее, но зато больше деталей видно. В ремуксе детали либо недосвечены, либо пересвечены.
>>58188
Потому что это невозможно. У тебя в SDR просто меньше цветов, чем есть в 2020, это конверсия с потерями. Во всех плеерах разные алгоритмы конверта, но все они не идеальные.
Потому что у тебя тогда будут дикие засветы/чернота, а цвета из HDR просто не существуют в SDR-пространстве, можно только примерно похожий влепить.
Потому что маппинг цветов на SDR - дело выбора конкретного алгоритма и вкуса.
Просто смотри на экране с поддержкой HDR10. Уже 2022 год, блять. Ты бы ещё спросил как в игре 2004 года сделать графон как в UE5.
> Почему всегда столько еботни и цвета все равно другие?
Потому что это невозможно. У тебя в SDR просто меньше цветов, чем есть в 2020, это конверсия с потерями. Во всех плеерах разные алгоритмы конверта, но все они не идеальные.
> Почему нельзя просто обрезать наиболее светлые и наиболее черные значения диапазона, которые выходят за рамки диапазона SDR, и уменьшить битность представления тех цветов/оттенков, которые таки входят в диапазон SDR, и получить ту же самую картинку, просто лишенную этой дополнительной точности?
Потому что у тебя тогда будут дикие засветы/чернота, а цвета из HDR просто не существуют в SDR-пространстве, можно только примерно похожий влепить.
> отличается от релиза этого же самого фильма
Потому что маппинг цветов на SDR - дело выбора конкретного алгоритма и вкуса.
> Почему оно ВОТ ТАК?
Просто смотри на экране с поддержкой HDR10. Уже 2022 год, блять. Ты бы ещё спросил как в игре 2004 года сделать графон как в UE5.
>>58251
Может быть и так, тут спорить не буду. Пожалуй, переформулирую мой вопрос так:
Вот у студии есть мастер-файл фильма на пару терабайт. Предполагаю, он 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-кадра стал малиновым, а в другом оранжевым?
Может быть и так, тут спорить не буду. Пожалуй, переформулирую мой вопрос так:
Вот у студии есть мастер-файл фильма на пару терабайт. Предполагаю, он 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-кадра стал малиновым, а в другом оранжевым?
>>58262
Пока писал свой ответ тому анону (см. выше), ты успел запостить свой. Отвечу тебе:
Да, это так, я в своих ночных сообщениях так и написал. Я вполне признаЮ, что пространство HDR шире (и, полагаю, более детализировано), чем SDR. Однако вопрос в том, почему у студии Paramount получился малиновый купальник, а у анонов из релиз-группы SWTYBLZ - оранжевый. Очевидно, оба получившихся цвета присутствуют в пространстве SDR. Но они же слишком далеко друг от друга, чтобы утверждать, что это разные способы округлить значение цвета из HDR-исходника до ближайших существующих цветов в SDR. Между этими двумя есть огромное количество разных цветов, можно градиент нарисовать.
Вот в этом и весь вопрос. В смысле блин дело вкуса? Если у меня есть число 0.256765765756 (очень точное, HDR) и мне нужно его округлить до сотых, чтобы записать в формате, где возможны только сотые (SDR), то я могу получить 0.25 или 0.26, в зависимости от метода округления, но никак не 0.42. Как здесь может быть "дело вкуса"?
Пока писал свой ответ тому анону (см. выше), ты успел запостить свой. Отвечу тебе:
> У тебя в SDR просто меньше цветов, чем есть в 2020, это конверсия с потерями.
> а цвета из HDR просто не существуют в SDR-пространстве
Да, это так, я в своих ночных сообщениях так и написал. Я вполне признаЮ, что пространство HDR шире (и, полагаю, более детализировано), чем SDR. Однако вопрос в том, почему у студии Paramount получился малиновый купальник, а у анонов из релиз-группы SWTYBLZ - оранжевый. Очевидно, оба получившихся цвета присутствуют в пространстве SDR. Но они же слишком далеко друг от друга, чтобы утверждать, что это разные способы округлить значение цвета из HDR-исходника до ближайших существующих цветов в SDR. Между этими двумя есть огромное количество разных цветов, можно градиент нарисовать.
> Потому что маппинг цветов на SDR - дело выбора конкретного алгоритма и вкуса.
Вот в этом и весь вопрос. В смысле блин дело вкуса? Если у меня есть число 0.256765765756 (очень точное, HDR) и мне нужно его округлить до сотых, чтобы записать в формате, где возможны только сотые (SDR), то я могу получить 0.25 или 0.26, в зависимости от метода округления, но никак не 0.42. Как здесь может быть "дело вкуса"?
3,9 Мб, 3840x2160>>58269
Потому что цветовое пространство не линейное. А тебя один цвет при разной яркости выглядит по разному, например красный может варьироваться от черно-бардового в тени до бледно-бело-красного на свету. А тут у тебя при конверте яркость срезается в разы. Когда ты видишь серые скрины HDR-кинца - это и есть "просто линейно сдвинуть цвета", пикрилейтед. Вот в этом и есть вся сложность - подобрать подходящий цвет при том что яркость уже совсем другая, алгоритм же не знает какой там на самом деле цвет. Для этого пилят сложные алгоритмы, которые угадывают что красный на картинке при таком-то количестве нит должен выглядеть вот так при другом.
Потому что цветовое пространство не линейное. А тебя один цвет при разной яркости выглядит по разному, например красный может варьироваться от черно-бардового в тени до бледно-бело-красного на свету. А тут у тебя при конверте яркость срезается в разы. Когда ты видишь серые скрины HDR-кинца - это и есть "просто линейно сдвинуть цвета", пикрилейтед. Вот в этом и есть вся сложность - подобрать подходящий цвет при том что яркость уже совсем другая, алгоритм же не знает какой там на самом деле цвет. Для этого пилят сложные алгоритмы, которые угадывают что красный на картинке при таком-то количестве нит должен выглядеть вот так при другом.
>>58262
Двачую. Это как проявка raw-фото в jpg. Идеального алгоритма не существует. Дело вкуса.
>маппинг цветов на SDR - дело выбора конкретного алгоритма и вкуса
Двачую. Это как проявка raw-фото в jpg. Идеального алгоритма не существует. Дело вкуса.
19,3 Мб, webm,1920x1080, 0:26
>>58269
Алсо, я вот с плойки 2020 PS5 не умеет в SDR конверчу в 709 вот таким фильтром в ffmpeg:
Получается видеорилейтед, на глаз цвета вполне похожи, хоть и не идеальны.
Алсо, я вот с плойки 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
Получается видеорилейтед, на глаз цвета вполне похожи, хоть и не идеальны.
>>58278
Да, я понимаю, что при - назовём это так - "наивном ужимании" всего более широкого диапазона 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.
Аналогию я понял, и в мире звука / обработки сигналов такого полно (ну буквально ремастер с теми или иными целями) - но ведь это уже получается сознательное вмешательство во внешний вид кадра, а не просто сухая лосси-конвертация из более широкого диапазона в более узкий. Я понимаю необходимость color grading (?) при создании фильма, т.е. при обработке нейтральных исходных кадров с камеры, чтобы придать фильму нужный внешний вид, да хоть в желтый все покрасить, потому что у нас лето во Флориде. Но зачем художественное вмешательство при перегоне готового фильма из HDR в SDR?
P.S. Я понимаю, что это переходит в какой-то нездоровый аутизм и вы все можете спросить "да нахуя тебе это, анон" (и будете правы). Но замечаю такое в SDR-релизах уже не в первый раз + логика этого разнится с привычной мне логикой обработки сигналов из мира звука, где лосси-перегон в формат представления с меньшей битностью или частотой дискретизации является вполне хорошо определенной и предсказуемой операцией, а все сознательные художественные изменения результата - совершенно отдельный процесс, не нужный при конвертации).
Да, я понимаю, что при - назовём это так - "наивном ужимании" всего более широкого диапазона 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-релизах уже не в первый раз + логика этого разнится с привычной мне логикой обработки сигналов из мира звука, где лосси-перегон в формат представления с меньшей битностью или частотой дискретизации является вполне хорошо определенной и предсказуемой операцией, а все сознательные художественные изменения результата - совершенно отдельный процесс, не нужный при конвертации).
>>58278
Да, я понимаю, что при - назовём это так - "наивном ужимании" всего более широкого диапазона 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.
Аналогию я понял, и в мире звука / обработки сигналов такого полно (ну буквально ремастер с теми или иными целями) - но ведь это уже получается сознательное вмешательство во внешний вид кадра, а не просто сухая лосси-конвертация из более широкого диапазона в более узкий. Я понимаю необходимость color grading (?) при создании фильма, т.е. при обработке нейтральных исходных кадров с камеры, чтобы придать фильму нужный внешний вид, да хоть в желтый все покрасить, потому что у нас лето во Флориде. Но зачем художественное вмешательство при перегоне готового фильма из HDR в SDR?
P.S. Я понимаю, что это переходит в какой-то нездоровый аутизм и вы все можете спросить "да нахуя тебе это, анон" (и будете правы). Но замечаю такое в SDR-релизах уже не в первый раз + логика этого разнится с привычной мне логикой обработки сигналов из мира звука, где лосси-перегон в формат представления с меньшей битностью или частотой дискретизации является вполне хорошо определенной и предсказуемой операцией, а все сознательные художественные изменения результата - совершенно отдельный процесс, не нужный при конвертации).
Да, я понимаю, что при - назовём это так - "наивном ужимании" всего более широкого диапазона 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-релизах уже не в первый раз + логика этого разнится с привычной мне логикой обработки сигналов из мира звука, где лосси-перегон в формат представления с меньшей битностью или частотой дискретизации является вполне хорошо определенной и предсказуемой операцией, а все сознательные художественные изменения результата - совершенно отдельный процесс, не нужный при конвертации).
>>58296
Так ты не знаешь оригинальную нелинейность гаммы. Ну отсёк ты его по краям, а в центре у тебя всё равно цвета не маппятся в нужные. В любом случае это "по вкусу" на глаз будет подгоняться, либо извращённой хуитой типа нейросетей.
> отсечение тех наиболее ярких и наиболее темных областей диапазона
Так ты не знаешь оригинальную нелинейность гаммы. Ну отсёк ты его по краям, а в центре у тебя всё равно цвета не маппятся в нужные. В любом случае это "по вкусу" на глаз будет подгоняться, либо извращённой хуитой типа нейросетей.
>>58300
В смысле не мапятся? Я понимаю, что HDR содержит 100500 оттенков красного, а SDR - только 100. Неужели нельзя мапнуть цвет на ближайший существующий в SDR красный, а не на какой-то еще другой красный?
Или вот в этих словах...
...ты имеешь в виду, что восприятие картинки глазом зависит от кривой гаммы экранов у тебя и у монтажёра в его оригинальной студии, и поэтому на мониторе с HDR оригинальный красный из HDR-видео и красный из одного из этих SDR-видео будут выглядеть одинаково на глаз?
И означает ли это, что, так как монтажёр фильма (и софт на его компе) знают "оригинальную нелинейность гаммы", то SDR-версия, которую он сделал вручную(?) в своей студии как раз выглядит идентично HDR-версии на его экране в том, что касается цветов, пусть и с потерей детализации градиентов и самых ярких и темных областей?
>а в центре у тебя всё равно цвета не маппятся в нужные
В смысле не мапятся? Я понимаю, что HDR содержит 100500 оттенков красного, а SDR - только 100. Неужели нельзя мапнуть цвет на ближайший существующий в SDR красный, а не на какой-то еще другой красный?
Или вот в этих словах...
> ты не знаешь оригинальную нелинейность гаммы
...ты имеешь в виду, что восприятие картинки глазом зависит от кривой гаммы экранов у тебя и у монтажёра в его оригинальной студии, и поэтому на мониторе с HDR оригинальный красный из HDR-видео и красный из одного из этих SDR-видео будут выглядеть одинаково на глаз?
И означает ли это, что, так как монтажёр фильма (и софт на его компе) знают "оригинальную нелинейность гаммы", то SDR-версия, которую он сделал вручную(?) в своей студии как раз выглядит идентично HDR-версии на его экране в том, что касается цветов, пусть и с потерей детализации градиентов и самых ярких и темных областей?
>>51062
Foobar умеет записывать в вавки так называемый RIFF INFO Chunk, который поддерживает все стандартные поля типа артист, тайтл, элбум и прочее. Это читается как теги и фубаром, и винампом, да и много ещё чем.
- мимокрок, знаю, что некрореплай
>И учитывая что тегов в wav нет
Foobar умеет записывать в вавки так называемый RIFF INFO Chunk, который поддерживает все стандартные поля типа артист, тайтл, элбум и прочее. Это читается как теги и фубаром, и винампом, да и много ещё чем.
- мимокрок, знаю, что некрореплай
>>58308
В том смысле что при съёмке цвета маппятся определённым образом. Когда ты не знаешь как их смапили, ты не знаешь какой там оригинальный цвет. Соответственно ты не можешь просто смаппить его в другое цветовое пространство, только "на глаз" подогнать. Ты ещё учти, что у алгоритма конвертирования нет "глаз", чтоб посмотреть похоже оно на то что в HDR или нет. И так же учти что по хорошему надо не срезать по краям диапазон, а сжимать а так всегда делают с кинцом и делают, что тоже цвета смещает.
>>58313
Ну там самое главное tonemap=hable. На пиках - хабл и ACES смаппленные RAW->HDR->SDR, и оригинал - смаппленый RAW->SDR.
> ты имеешь в виду
В том смысле что при съёмке цвета маппятся определённым образом. Когда ты не знаешь как их смапили, ты не знаешь какой там оригинальный цвет. Соответственно ты не можешь просто смаппить его в другое цветовое пространство, только "на глаз" подогнать. Ты ещё учти, что у алгоритма конвертирования нет "глаз", чтоб посмотреть похоже оно на то что в HDR или нет. И так же учти что по хорошему надо не срезать по краям диапазон, а сжимать а так всегда делают с кинцом и делают, что тоже цвета смещает.
>>58313
Ну там самое главное tonemap=hable. На пиках - хабл и ACES смаппленные RAW->HDR->SDR, и оригинал - смаппленый RAW->SDR.
>>58316
Если честно, это меня как раз здорово смутило в твоем предыдущем сообщении, и как раз по этой причине. Если сжать весь диапазон от самого темного HDR-цвета до самого яркого в SDR-диапазон от умеренно темного до умеренно яркого, то как и получится типичная серая блёклая картинка, как ты запостил скрин выше вот тут >>58278 , потому что "просто темные" оттенки уедут в темно-серые, а "просто светлые" в светло-серые.
Если тот человек, который делал для Paramount 1080p SDR версию для блюрея, в своей студии откроет на экране в видеоплеере оригинальный фильм HDR и свою SDR версию, то малиново-красный цвет купальника там будет выглядеть одинаково (если он сознательно его не перекрашивал)? А, в свою очередь, более "оранжевая" версия от SWTYBLZ будет выглядеть на его экране неправильно? Но при этом где-то в мире существует монитор, на котором как раз "оранжевая" версия от SWTYBLZ выглядит так же, как HDR - по крайней мере, по мнению алгоритма в том кодеке, который они применили?
>по хорошему надо не срезать по краям диапазон, а сжимать
Если честно, это меня как раз здорово смутило в твоем предыдущем сообщении, и как раз по этой причине. Если сжать весь диапазон от самого темного HDR-цвета до самого яркого в SDR-диапазон от умеренно темного до умеренно яркого, то как и получится типичная серая блёклая картинка, как ты запостил скрин выше вот тут >>58278 , потому что "просто темные" оттенки уедут в темно-серые, а "просто светлые" в светло-серые.
Если тот человек, который делал для Paramount 1080p SDR версию для блюрея, в своей студии откроет на экране в видеоплеере оригинальный фильм HDR и свою SDR версию, то малиново-красный цвет купальника там будет выглядеть одинаково (если он сознательно его не перекрашивал)? А, в свою очередь, более "оранжевая" версия от SWTYBLZ будет выглядеть на его экране неправильно? Но при этом где-то в мире существует монитор, на котором как раз "оранжевая" версия от SWTYBLZ выглядит так же, как HDR - по крайней мере, по мнению алгоритма в том кодеке, который они применили?
>>58316
Вдогонку, по поводу слов про нелинейность гаммы. В играх, даже в старых, вышедших задолго до эпохи HDR, нередко есть настройка гаммы, от "ебать темно ничего не видно" до "всё серое и выцветшее". Это как-то связано со всем этим? В том смысле, что итоговую похожесть картинки на некий идеальный референс (цветов, яркости и пр.) все равно определяет только индивидуальная настройка под конкретный монитор?
Вдогонку, по поводу слов про нелинейность гаммы. В играх, даже в старых, вышедших задолго до эпохи HDR, нередко есть настройка гаммы, от "ебать темно ничего не видно" до "всё серое и выцветшее". Это как-то связано со всем этим? В том смысле, что итоговую похожесть картинки на некий идеальный референс (цветов, яркости и пр.) все равно определяет только индивидуальная настройка под конкретный монитор?
601 Кб, 990x557>>58320
Для этого и надо маппить нелинейно, как на пикрилейтед. А если срезать, то теряются детали на засветах/черноте.
Она нигде не выглядит так же, просто тот васян не хотел или не мог сравнить с HDR на глаз. А алгоритм не может "видеть", ему для этого нужен какой-то внешний референс чтоб сравнивать.
> потому что "просто темные" оттенки уедут в темно-серые, а "просто светлые" в светло-серые
Для этого и надо маппить нелинейно, как на пикрилейтед. А если срезать, то теряются детали на засветах/черноте.
> "оранжевая" версия от SWTYBLZ выглядит так же, как HDR
Она нигде не выглядит так же, просто тот васян не хотел или не мог сравнить с HDR на глаз. А алгоритм не может "видеть", ему для этого нужен какой-то внешний референс чтоб сравнивать.
>>58323
Теряются, но хуле поделать, это ограничение конечного формата. Так-то и при перегоне из HD в 320x240 теряются детали изображения. ¯\_(ツ)_/¯ Идея понятна, но не уверен, что "согласен" со средствами достижения цели. Вот на моих скринах из Baywatch в версии 1080p SDR плохо видно детали пейзажа за окнами, потому что ярко и засвечено. Но тут, как бы, а хуле поделать-то? Заметно менее яркая / более детальная прорисовка задника будет выглядеть странно, потому что глаз человека ожидает огромного контраста между людьми в помещении и ярким пейзажем снаружи.
кстати, этот задник - графон, на самом деле за окнами был зелёный экран
А что, реально взять HDR-релиз в 3840x2160, скормить его алгоритму и дать в качестве референса официальный блюрей SDR 1920x1080, чтобы сохранились оттенки цветов и яркость? То есть, "возьми детализацию из 4K HDR релиза, а по поводу цветов сверяйся с 1080 SDR"?
Сам я вряд ли буду этим заниматься, но если да, то странно, почему так не делают.
>А если срезать, то теряются детали на засветах/черноте.
Теряются, но хуле поделать, это ограничение конечного формата. Так-то и при перегоне из HD в 320x240 теряются детали изображения. ¯\_(ツ)_/¯ Идея понятна, но не уверен, что "согласен" со средствами достижения цели. Вот на моих скринах из Baywatch в версии 1080p SDR плохо видно детали пейзажа за окнами, потому что ярко и засвечено. Но тут, как бы, а хуле поделать-то? Заметно менее яркая / более детальная прорисовка задника будет выглядеть странно, потому что глаз человека ожидает огромного контраста между людьми в помещении и ярким пейзажем снаружи.
кстати, этот задник - графон, на самом деле за окнами был зелёный экран
> А алгоритм не может "видеть", ему для этого нужен какой-то внешний референс чтоб сравнивать.
А что, реально взять HDR-релиз в 3840x2160, скормить его алгоритму и дать в качестве референса официальный блюрей SDR 1920x1080, чтобы сохранились оттенки цветов и яркость? То есть, "возьми детализацию из 4K HDR релиза, а по поводу цветов сверяйся с 1080 SDR"?
Сам я вряд ли буду этим заниматься, но если да, то странно, почему так не делают.
56 Кб, 1244x735>>58321
Да. Всё серое - это ты получишь если смаппить линейно. Можно смаппить по нелинейным, типа хабла или ACES, но как видишь там тоже не попадает в цвета.
Только формулы разные бывают. Там может быть сильно сложнее квадратичной функции.
Да. Всё серое - это ты получишь если смаппить линейно. Можно смаппить по нелинейным, типа хабла или ACES, но как видишь там тоже не попадает в цвета.
> в старых, вышедших задолго до эпохи HDR, нередко есть настройка гаммы
Только формулы разные бывают. Там может быть сильно сложнее квадратичной функции.
>>58324
Под референсом я имею ввиду изображение этих двух форматов в каком-то одном. Например RAW-фото картинки на экране в HDR и SDR. Это то что ты на глаз можешь сделать и алгоритм - нет.
Под референсом я имею ввиду изображение этих двух форматов в каком-то одном. Например RAW-фото картинки на экране в HDR и SDR. Это то что ты на глаз можешь сделать и алгоритм - нет.
>>58188
Не много не по теме, но я сравнил твои скрины, и пришел к выводу, что релиз группы картинка лучше.
Во первых там контрастность будет выше (из-за чего сиськи выглядят объёмнее).
Во вторых на твоей 1080p SDR кожа зеленит. А у транскода нет этого избыточного зелёного, из-за чего кожа выглядит более загорелой. (Хотя кто его знает, как оно там объективно по цветам. У меня TN монитор, мог и перекосоёбить цвета.)
Не много не по теме, но я сравнил твои скрины, и пришел к выводу, что релиз группы картинка лучше.
Во первых там контрастность будет выше (из-за чего сиськи выглядят объёмнее).
Во вторых на твоей 1080p SDR кожа зеленит. А у транскода нет этого избыточного зелёного, из-за чего кожа выглядит более загорелой. (Хотя кто его знает, как оно там объективно по цветам. У меня TN монитор, мог и перекосоёбить цвета.)
>>58336
Ну почему не по теме, норм.
Но мне кажется, что у релиз-группы получилось темнее и заметно холоднее. Особенно хорошо видно на пейзаже за окном и на серой вертикальной поверхности стола позади ног. 1080 с блюрея теплее и ярче, чуточку желтоватый. 4K SDR от релиз-группы холоднее и тусклее. (а вот кожа таки да, немного зеленоватая в 1080 и немного красноватая в 4K).
Имхо, главный минус самопального HDR->SDR от SWTYBLZ - голубоватая дымка, которая покрывает всё. Видел такое и в других их релизах. Насколько это заметно при просмотре человеком, который не видел "тру референс" в виде официального 1080 SDR с блюрея - хз. Насколько это "важно" - тем более хз. Но при сравнении эта разница очевидна.
Аргумент про контраст и сиськи важный, да. :D
Вообще, возможно, Baywatch был не лучшим примером для вот этого всего, т.к. в этом фильме 4K - фейковый и просто апспкейл из 2K, это хорошо видно при рассмотрении деталей кадра в настоящем масштабе 1:1 на экране, всё либо мыльное, либо "лесенки" идут отчетливо с шагом в 2 пикселя, особенно обводка зеленого экрана вокруг плеч Скалы. Но существуют и честные 4K фильмы. Тащемта, всё вот это вот началось с того, что я решил сделать гифку с Даддарио и полез за качественным исходником.
Ну почему не по теме, норм.
Но мне кажется, что у релиз-группы получилось темнее и заметно холоднее. Особенно хорошо видно на пейзаже за окном и на серой вертикальной поверхности стола позади ног. 1080 с блюрея теплее и ярче, чуточку желтоватый. 4K SDR от релиз-группы холоднее и тусклее. (а вот кожа таки да, немного зеленоватая в 1080 и немного красноватая в 4K).
Имхо, главный минус самопального HDR->SDR от SWTYBLZ - голубоватая дымка, которая покрывает всё. Видел такое и в других их релизах. Насколько это заметно при просмотре человеком, который не видел "тру референс" в виде официального 1080 SDR с блюрея - хз. Насколько это "важно" - тем более хз. Но при сравнении эта разница очевидна.
Аргумент про контраст и сиськи важный, да. :D
Вообще, возможно, Baywatch был не лучшим примером для вот этого всего, т.к. в этом фильме 4K - фейковый и просто апспкейл из 2K, это хорошо видно при рассмотрении деталей кадра в настоящем масштабе 1:1 на экране, всё либо мыльное, либо "лесенки" идут отчетливо с шагом в 2 пикселя, особенно обводка зеленого экрана вокруг плеч Скалы. Но существуют и честные 4K фильмы. Тащемта, всё вот это вот началось с того, что я решил сделать гифку с Даддарио и полез за качественным исходником.
>>58455
Полюбоваться артефактами aomenc на битрейте 80 kbps, и, возможно даже, словить артефакт компрессии от libopus 80kbps.
Полюбоваться артефактами aomenc на битрейте 80 kbps, и, возможно даже, словить артефакт компрессии от libopus 80kbps.
>>58500
-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 "
-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 "
>>58614
То что это ненужный хохляцкий костыль, svt-av1 нагружает все ядра без всякой хуйни
То что это ненужный хохляцкий костыль, svt-av1 нагружает все ядра без всякой хуйни
>>58616
Так ведь svt даёт не такую качественную картинку как aomenc. Или у тебя пунктик на хохлах?
Так ведь svt даёт не такую качественную картинку как aomenc. Или у тебя пунктик на хохлах?
8 Мб, webm,640x360, 23:42
>>58517
Просрал весь битрейт на опус, хотя вплоть до 17кбс не слышно даже значимых артефактов, сам проверял. Сейчас мб даже лучше.
не максимальные настройки nuff said
не mode 2
И как я понял еще без 2pass.
Учись, сынизде. При этом сделано на древней версии 1.5 года назад.
>-c:a libopus -b:a 80k
Просрал весь битрейт на опус, хотя вплоть до 17кбс не слышно даже значимых артефактов, сам проверял. Сейчас мб даже лучше.
>--cpu-used=2
не максимальные настройки nuff said
>--aq-mode=1
не mode 2
И как я понял еще без 2pass.
Учись, сынизде. При этом сделано на древней версии 1.5 года назад.
>>58714
УМВР.
УМВР.
>>58686
У av1an для aomenc там по дефолту стоит 2pass.
Для music video самое то. Твои 17 kbps годятся разве что для говорящих голов.
просвети, в чём разница?
> И как я понял еще без 2pass.
У av1an для aomenc там по дефолту стоит 2pass.
> Просрал весь битрейт на опус
Для music video самое то. Твои 17 kbps годятся разве что для говорящих голов.
>>--aq-mode=1
>не mode 2
просвети, в чём разница?
87 Кб, 654x374>>58686
Ситуация аналогичная посту выше. Хотя моё видео у меня открывается.
В общем посмотрел я твоё видео. 48 kbps это конечно мощно, но для 360p этого очень мало. В своё время 3gp с таким битрейтом кодировали, так там разрешение было около 144p, и всё равно шакалы лезли.
Ситуация аналогичная посту выше. Хотя моё видео у меня открывается.
В общем посмотрел я твоё видео. 48 kbps это конечно мощно, но для 360p этого очень мало. В своё время 3gp с таким битрейтом кодировали, так там разрешение было около 144p, и всё равно шакалы лезли.
>>58961
Оба видео matroska,webm, у них только одно не открывается.
> Вероятно потому что нет поддержки mkv
Оба видео matroska,webm, у них только одно не открывается.
>>58990
ну фиг знает. У меня тоже некоторые с mkv не открывались. Может из-за тегов. Danmachi webm переведена с mkv орига.
ну фиг знает. У меня тоже некоторые с mkv не открывались. Может из-за тегов. Danmachi webm переведена с mkv орига.
>>58714
Поздравляю. Ты попался под влияние софтошиза. Для обратного становления человеком форматно диск нулями и поставь софт для белых людей, а не рабов пердоговна.
Поздравляю. Ты попался под влияние софтошиза. Для обратного становления человеком форматно диск нулями и поставь софт для белых людей, а не рабов пердоговна.
>>58961
Ну не совсем. То видео успешно проигрывается ровно 2 секунды. После чего - то, что на скрине.
> Вероятно потому что нет поддержки mkv
Ну не совсем. То видео успешно проигрывается ровно 2 секунды. После чего - то, что на скрине.
Может ли ффмпег записывать видео с отдельной вкладки/окна браузера с проигрывающимся видео, когда это окно свернуто?
47 Кб, 879x577>>59229
А мне это не нужно делать, дегрельный. Для особо одарённых объясняю: те сайты, которые макаки пишут только под сром в лисе запускаются в рамках расширения webcompat, так что не серь подсибя больше так обильно.
Благо, такого говна критически мало, то есть, для ff пользователей не плачевно.
Набери about:compat и убедись.
А мне это не нужно делать, дегрельный. Для особо одарённых объясняю: те сайты, которые макаки пишут только под сром в лисе запускаются в рамках расширения webcompat, так что не серь подсибя больше так обильно.
Благо, такого говна критически мало, то есть, для ff пользователей не плачевно.
Набери about:compat и убедись.
>>59321
Что такое квантование ты можешь почитать и в википедии. Квантование изображения приводит к уменьшению глубины цвета.
Другое дело, если перед квантованием произвести какое-то преобразование изображения. Самое популярное преобразование это ДКП. А вот уже квантование ДКП коэффициентов приводит к другой, менее заметной деградации изображения. Хотя практика применения JPEG показывает, что большой квантователь также приводит к уменьшению глубины цвета.
Что такое квантование ты можешь почитать и в википедии. Квантование изображения приводит к уменьшению глубины цвета.
Другое дело, если перед квантованием произвести какое-то преобразование изображения. Самое популярное преобразование это ДКП. А вот уже квантование ДКП коэффициентов приводит к другой, менее заметной деградации изображения. Хотя практика применения JPEG показывает, что большой квантователь также приводит к уменьшению глубины цвета.
>>59338
По каким?
По каким?
>>59250
скачай обс и не пердолься.
скачай обс и не пердолься.
>>51348
>>51250
>>51147
>>51137
Возвращаясь к этому обсуждению кодека TAk:
Сегодня захотел записать длинный текст в комментарии к альбому flac-файлов. Плеер - Foobar2000, для просмотра тегов использую плагин Text Display - в дефолтном просмотрщике тегов много мусора (MD5 суммы, например), который никак не скрыть, Text Display же полностью настраивается. Текст был по большей части на русском языке. Сохранив тег, я этот текст не увидел. Перевёл на английский язык, вставил - текст виден. Короткие тексты на русском были видны. И, кажется, многострочные тексты в комментарии не показывались, если на русском.
Виной проблемы был плагин - через редактор тегов, встроенный в foobar, эти теги видны.
Однако, я вставил тот же длинный русский текст в комментарий к mp3-файлу. И в mp3 он виден.
Перекодировал flac в tak, перенёс теги. Текст на русском стал виден вне зависимости от длинны. Ещё и парочку мегабайт сэкономил.
Вывод - TAK намного лучше работает с тегами, FLAC - попущен.
>>51250
>>51147
>>51137
Возвращаясь к этому обсуждению кодека TAk:
Сегодня захотел записать длинный текст в комментарии к альбому flac-файлов. Плеер - Foobar2000, для просмотра тегов использую плагин Text Display - в дефолтном просмотрщике тегов много мусора (MD5 суммы, например), который никак не скрыть, Text Display же полностью настраивается. Текст был по большей части на русском языке. Сохранив тег, я этот текст не увидел. Перевёл на английский язык, вставил - текст виден. Короткие тексты на русском были видны. И, кажется, многострочные тексты в комментарии не показывались, если на русском.
Виной проблемы был плагин - через редактор тегов, встроенный в foobar, эти теги видны.
Однако, я вставил тот же длинный русский текст в комментарий к mp3-файлу. И в mp3 он виден.
Перекодировал flac в tak, перенёс теги. Текст на русском стал виден вне зависимости от длинны. Ещё и парочку мегабайт сэкономил.
Вывод - TAK намного лучше работает с тегами, FLAC - попущен.
>>59885
Скорее ты, так как не осилил Vorbis Comments, а делал всё через ветпаськи, бгг
> FLAC - попущен
Скорее ты, так как не осилил Vorbis Comments, а делал всё через ветпаськи, бгг
>>59887
И где я должен был найти решение проблемы с Vorbis Comments? Я ведь даже не знаю, что это за проблема - в тегах, в кодировке, или в том как разные программы читают теги, или в чём-то ещё. Я просто не знаю, куда копать, у меня нет вводных, чтобы вбить поисковый запрос и найти информацию о решении проблемы.
Что именно ветпаська, и по какому критерию? Для меня ветпаська - это CCleaner, Avast, Driver Booster.
И где я должен был найти решение проблемы с Vorbis Comments? Я ведь даже не знаю, что это за проблема - в тегах, в кодировке, или в том как разные программы читают теги, или в чём-то ещё. Я просто не знаю, куда копать, у меня нет вводных, чтобы вбить поисковый запрос и найти информацию о решении проблемы.
>ветпаськи
Что именно ветпаська, и по какому критерию? Для меня ветпаська - это CCleaner, Avast, Driver Booster.
17 Кб, 523x353>>59885
Вот это:
А вот это:
Не ветпась.
> Что именно ветпаська, и по какому критерию?
Вот это:
> плагин Text Display
> дефолтном просмотрщике тегов foobar2000
А вот это:
Не ветпась.
486 Кб, 546x292>>59901
Позволяет смотреть только нужные мне теги, а не всю существующую в компьютерном мире хуиту, от файлового пути до md5-сумм (очень нужно во время прослушивания!).
По твоей логике и компьютеры не нужны - это одна огромная ветпась! У людей есть калькуляторы и пишущие машинки, значит компьютеры нинужны. Вообще, технический прогресс нинужон.
>> плагин Text Display
Позволяет смотреть только нужные мне теги, а не всю существующую в компьютерном мире хуиту, от файлового пути до md5-сумм (очень нужно во время прослушивания!).
По твоей логике и компьютеры не нужны - это одна огромная ветпась! У людей есть калькуляторы и пишущие машинки, значит компьютеры нинужны. Вообще, технический прогресс нинужон.
>>59907
Ну сиди тогда без нормальных UTF-8 тегов стандарта теггирования кодеков от Xiph.org, используя вместо этого васянский суррогат.
Ну сиди тогда без нормальных UTF-8 тегов стандарта теггирования кодеков от Xiph.org, используя вместо этого васянский суррогат.
>>59908
Предпочту легковесные TAK-файлы в сочетании с удобным Text Display.
Предпочту легковесные TAK-файлы в сочетании с удобным Text Display.
251 Кб, 1422x455Ну значит попробовал я ваш svt, и знаете что? Там всё равно нужен av1an.
>>59901
vorbiscomment только для ogg файлов, судя по
vorbiscomment только для ogg файлов, судя по
>Failed to open file as Vorbis: Input is not an Ogg bitstream.
>>60041
Из-за чего произошла проблема, с которой я столкнулся? Из-за кодировки (доисторическая кодировка, не выдерживает много букв кириллицы)?
Из-за чего произошла проблема, с которой я столкнулся? Из-за кодировки (доисторическая кодировка, не выдерживает много букв кириллицы)?
>>60058
Кодировка UTF-8, если через Vorbiscomment делать, так как этот стандарт предусматривает кодировку UTF-8. Скорее всего, твой плагин в какой-то другой кодировке это пишет, иди стандарт теггирования применяет другой.
Кодировка UTF-8, если через Vorbiscomment делать, так как этот стандарт предусматривает кодировку UTF-8. Скорее всего, твой плагин в какой-то другой кодировке это пишет, иди стандарт теггирования применяет другой.
>>60069
Мой плагин - Text Display - показывает теги в удобном настраиваемом окне. Теги записывал через Properties в контекстном меню Foobar2000. Через Mp3tag так же записывал. Через metaflac так же записывал.
Проблема в том, как Text Display читает теги. Но в mp3, tak, и возможно других форматах, он читает тот же самый текст. А вот во flac вместо текста - точка. Я лучше перекодирую свою музыку в TAK, параллельно сэкономив на дисковом пространстве, чем буду наворачивать дефолтный кал и каждый раз отвлекаться на ненужные мне мне данные, которые никак не скрыть.
Ахаха! Дефолтный вьювер тегов Selection Properties тоже не осиливает длинный текст на кириллице, вот только не осиливает его ни в одном формате - flac, mp3, tak. Text Display этот текст только в flac не осиливает. Оригинал оказался хуже "васянки", бгг.
>Скорее всего, твой плагин в какой-то другой кодировке это пишет, иди стандарт теггирования применяет другой.
Мой плагин - Text Display - показывает теги в удобном настраиваемом окне. Теги записывал через Properties в контекстном меню Foobar2000. Через Mp3tag так же записывал. Через metaflac так же записывал.
Проблема в том, как Text Display читает теги. Но в mp3, tak, и возможно других форматах, он читает тот же самый текст. А вот во flac вместо текста - точка. Я лучше перекодирую свою музыку в TAK, параллельно сэкономив на дисковом пространстве, чем буду наворачивать дефолтный кал и каждый раз отвлекаться на ненужные мне мне данные, которые никак не скрыть.
Ахаха! Дефолтный вьювер тегов Selection Properties тоже не осиливает длинный текст на кириллице, вот только не осиливает его ни в одном формате - flac, mp3, tak. Text Display этот текст только в flac не осиливает. Оригинал оказался хуже "васянки", бгг.
Какой наиболее простой способ раскидать задачи по нескольким компам? К примеру есть папка с видосами, я сделал команду для ffmpeg, и не хочу вручную раскидывать это по разным компам, подключаться по ssh и следить когда они закончат, а потом скопировать обратно, мне нужно чтоб это автоматически было
93 Кб, 954x537Первый раз вижу такой битрейт на трубе, еще и 6 каналов, но нахуя, там даже не третий уе
35 Кб, 1028x172>>60757
Лол действительно есть ac-3, ec-3 и 387к 194k aac.
Лол действительно есть ac-3, ec-3 и 387к 194k aac.
>>60797
Я в курсе что порт порезан, но хоть графон завезли на бета версии трехи (2.5). Серия именно с этой части стала многострадальной хуйней, конвикшн они вообще три раза с нуля переделывали, лол. Итого вышла опять темной сранью после светлой DA, чего не скажешь про изначальные дропы концептов конвикшн, которые в каких-то журналах были показаны бомжом главного героя.
Я в курсе что порт порезан, но хоть графон завезли на бета версии трехи (2.5). Серия именно с этой части стала многострадальной хуйней, конвикшн они вообще три раза с нуля переделывали, лол. Итого вышла опять темной сранью после светлой DA, чего не скажешь про изначальные дропы концептов конвикшн, которые в каких-то журналах были показаны бомжом главного героя.
>>60810
Оригинальная DA была тёмной. Это в китайском порте все миссии днём сделали, что порушило весь концепт SC.
> Итого вышла опять темной сранью после светлой DA
Оригинальная DA была тёмной. Это в китайском порте все миссии днём сделали, что порушило весь концепт SC.
>>60812
Я в курсе, мне это наоборот зашло. В киношном блэклисте тоже светло, как и в дропнутой версии конвикшна.
Я в курсе, мне это наоборот зашло. В киношном блэклисте тоже светло, как и в дропнутой версии конвикшна.
>>60812
Саунд дизайн там кстати хороший. Еще и free dl от автора, но lossless не сливает, жадина https://michaelmccann.io/projects/splinter-cell-double-agent-soundtrack/
>DA
Саунд дизайн там кстати хороший. Еще и free dl от автора, но lossless не сливает, жадина https://michaelmccann.io/projects/splinter-cell-double-agent-soundtrack/
443 Кб, 967x544Какое железо нужно для быстрого кодирования VP9? Есть ли поддержка ускорения этого кодека у нвидиа?
>>60925
Говорят у будующих Intel ARC будет аппаратный кодировщик AV1. Да, немного не по теме, но аппаратное кодирование AV1 сделает ненужным кодирование в VP9.
Говорят у будующих Intel ARC будет аппаратный кодировщик AV1. Да, немного не по теме, но аппаратное кодирование AV1 сделает ненужным кодирование в VP9.
Ребят, подскажите пожалуйста, как можно в скрипте реализовать вывод сообщения об ошибке. Приведу пример, с которым не раз сталкивался: если ресайзить видос с сохранением пропорций, то не всегда это возможно из-за того, что одна из сторон будет не целым числом. ффмпег в этом случае выводит соответствующее сообщение об ошибке. Такой вопрос: как можно либо избежать такой ситуации вообще, либо в скрипте вывести именно это сообщение об ошибке(то есть в случае этой ошибке, чтобы именно это сообщение записалось в файл/вывело в стдаут и тд)
>>60925
Без разниц, хватит средней мощности это говно все равно не умеет в распараллеливание ресурсов, ядер и нагрузки на них.
Нет, только у интуля вроде есть в последних процессорах.
> Какое железо нужно для быстрого кодирования VP9?
Без разниц, хватит средней мощности это говно все равно не умеет в распараллеливание ресурсов, ядер и нагрузки на них.
> Есть ли поддержка ускорения этого кодека у нвидиа?
Нет, только у интуля вроде есть в последних процессорах.
>>61175
Software > Nvenc > QSV > AMD VCE
Software > Nvenc > QSV > AMD VCE
>>61110
А ты возьми и округли до целого. ffmpeg должен в метаданных прописать истинное соотношение сторон.
> если ресайзить видос с сохранением пропорций, то не всегда это возможно из-за того, что одна из сторон будет не целым числом.
А ты возьми и округли до целого. ffmpeg должен в метаданных прописать истинное соотношение сторон.
>>61128
Интересно как на плойке аппаратное кодирование в VP9 работает. Там же фактически рязань стоит.
> только у интуля вроде есть в последних процессорах
Интересно как на плойке аппаратное кодирование в VP9 работает. Там же фактически рязань стоит.
>>61897
Почему тогда на пука нельзя?
Почему тогда на пука нельзя?
Есть ли такая же удобная программа, как boram особенно нравится crop простым выделением, но с h.264 и которая все ещё поддерживается?
>>61981
То что надо. Спасибо.
То что надо. Спасибо.
Видел на дваче mp4, у которых длительность отображается 5 секунд к примеру, но при воспроизведении они играют дольше. Подскажите, как такие делать?
Вопрос: есть несколько сотен ави файлов (кино, сериалы) размером общим под пару сотен Гб, хотелось бы их конвертировать в mkv с заменой кодека divx на другой.
Есть какой-то простой метод как это сделать, или проще будет тупо скачать с торрентов в другом формате даже с учётом затрат времени на поиск?
Есть какой-то простой метод как это сделать, или проще будет тупо скачать с торрентов в другом формате даже с учётом затрат времени на поиск?
>>63351
Ты бы ещё конечную цель написал. Уж явно не со скуки ты это придумал.
Конечно проще. Сотни гигабайт ты будешь рендерить на своей домашней пеке до второго пришествия, если есть цель сохранить качество.
Ты бы ещё конечную цель написал. Уж явно не со скуки ты это придумал.
>проще будет тупо скачать с торрентов в другом формате даже с учётом затрат времени на поиск?
Конечно проще. Сотни гигабайт ты будешь рендерить на своей домашней пеке до второго пришествия, если есть цель сохранить качество.
>>63359
Купил телик а он дивикс не читает, а у меня коллекция киношек на внешнем харде вся по пизде из-за этого.
Купил телик а он дивикс не читает, а у меня коллекция киношек на внешнем харде вся по пизде из-за этого.
>>63360
Если так ценна коллекция, то купи приставку, которая читает то что тебе нужно. А может на телик можно поставить приложение, которое читает? Я с теликами не очень.
Если так ценна коллекция, то купи приставку, которая читает то что тебе нужно. А может на телик можно поставить приложение, которое читает? Я с теликами не очень.
>>63361
Это и есть самый простой выход.
Это и есть самый простой выход.
Аноны, а возможно ли как-то пожать png-изображения энкодером H264 и обратно в png? Причём изображения разного размера, вариант с кодированием видео из изображений и потом извлечением их не подходит. Нужно для обучения нейросетей, нужна именно деградация изображений от H264. Или может есть какой-то формат изображений, дающий такие же артефакты? Жипеги вообще не подходят, там блоки одного размера, резкость сильно ниже, нет артефактов границ объектов в виде пилы.
>>66754
Просто берёшь и без задней мысли кодируешь, не понимаю твой вопрос, делай 1 фреймовые видео циклом, затем циклом обратно все видео в пгн гони или что ты конкретно хочешь?
Просто берёшь и без задней мысли кодируешь, не понимаю твой вопрос, делай 1 фреймовые видео циклом, затем циклом обратно все видео в пгн гони или что ты конкретно хочешь?
>>66767
>>66787
Можете примерно почувствовать сколько будет конвертить 10к хайрез пикчей таким способом? Если сутки, то это не мой вариант я это буду делать явно не раз и не два, в жипеги я за 30 минут жал скриптом на C#.
Real-ESRGAN, на жипегах уже сделал 500к итераций, результат получился сильно лучше топаза.
>>66787
> делай 1 фреймовые видео циклом
> ffmpeg -i 1.mkv -vframes 1 -c:v libx264 out.mkv
Можете примерно почувствовать сколько будет конвертить 10к хайрез пикчей таким способом? Если сутки, то это не мой вариант я это буду делать явно не раз и не два, в жипеги я за 30 минут жал скриптом на C#.
> Что за нейросеть?
Real-ESRGAN, на жипегах уже сделал 500к итераций, результат получился сильно лучше топаза.
>>66800
Ну 7к хуйрез из png в webp lossless у меня что-то вроде получаса на 3.6 хасвелле ушло, не думаю, что в 264 дольше будет кодировать. В любом случае поставь, да посмотри, устраивает тебя время или нет. Других вариантов особо не видно.
> Можете примерно почувствовать сколько будет конвертить 10к хайрез пикчей таким способом
Ну 7к хуйрез из png в webp lossless у меня что-то вроде получаса на 3.6 хасвелле ушло, не думаю, что в 264 дольше будет кодировать. В любом случае поставь, да посмотри, устраивает тебя время или нет. Других вариантов особо не видно.
>>66800
X264 хорошо масштабируется. Время кодирование целиком зависит от твоего процессора.
X264 хорошо масштабируется. Время кодирование целиком зависит от твоего процессора.
>>66800
Если 10000 картинок лучше их конвертировать как непрерывное видео, для честности с -g 1, каждый кадр будет сжат по отдельности
Получается всего 5 минут и сжиматься будет минут 10-15
Если 10000 картинок лучше их конвертировать как непрерывное видео, для честности с -g 1, каждый кадр будет сжат по отдельности
Получается всего 5 минут и сжиматься будет минут 10-15
Есть видео на 20 гб, в 5 фпс.
Нужно взять пачки по 50 кадров, объединить в отдельные кадры (просто среднее по 50 кадрам, чтобы шум убрать), и после склеить в нормальное видео из таких кадров.
Я бы мог разрезать на отдельные кадры и сделать вручную программой, но по оценке разрезанное на картинки видео будет занимать около 300 гб - у меня столько нету. А если я просто ставлю фпс в 0.1, то он скипает кадры, а не берёт среднее по кадрам.
Есть функция, которая такое умеет?
Может есть биндинг ffmpeg под питон в котором я смогу разобраться (в идеале - мне нужна функция "извлечь кадр из исходного видео" и "записать кадр в выходное видео") и где смогу такое написать и он без сохранения на диск сможет объединять группы кадров и записывать обратно? Посоветуйте что-то, пожалуйста. В описании всяких фильтров по типу fps или setpts ничего не вижу.
Нужно взять пачки по 50 кадров, объединить в отдельные кадры (просто среднее по 50 кадрам, чтобы шум убрать), и после склеить в нормальное видео из таких кадров.
Я бы мог разрезать на отдельные кадры и сделать вручную программой, но по оценке разрезанное на картинки видео будет занимать около 300 гб - у меня столько нету. А если я просто ставлю фпс в 0.1, то он скипает кадры, а не берёт среднее по кадрам.
Есть функция, которая такое умеет?
Может есть биндинг ffmpeg под питон в котором я смогу разобраться (в идеале - мне нужна функция "извлечь кадр из исходного видео" и "записать кадр в выходное видео") и где смогу такое написать и он без сохранения на диск сможет объединять группы кадров и записывать обратно? Посоветуйте что-то, пожалуйста. В описании всяких фильтров по типу fps или setpts ничего не вижу.
>>67256
Чё вообще еблан? Это называется frame blending https://unix.stackexchange.com/questions/178503/ffmpeg-interpolate-frames-or-add-motion-blur
Чё вообще еблан? Это называется frame blending https://unix.stackexchange.com/questions/178503/ffmpeg-interpolate-frames-or-add-motion-blur
>>67262
Я то откуда знаю как это называется?
Я могу написать код, если у меня есть массивы пикселей, а догадаться как это люди назвали...
Спасибо, сработал tmix как надо.
А подскажешь ещё штуку? Нужно из кадров получать среднюю яркость, и видео затемнять-осветлять выравнивая отдельные кадры до одинаковой яркости. Если оно как-то сможет сделать это интеллектуально не просто умножая яркости на 0.8, а правя кривые и делая гистограмму более равномерное - то только лучше. Хотя и тупое умножение на 0.8 или на 1.2 подойдёт, даже если там светлые части засветятся, главное чтобы средняя яркость всего кадра была такая же.
Я то откуда знаю как это называется?
Я могу написать код, если у меня есть массивы пикселей, а догадаться как это люди назвали...
Спасибо, сработал tmix как надо.
А подскажешь ещё штуку? Нужно из кадров получать среднюю яркость, и видео затемнять-осветлять выравнивая отдельные кадры до одинаковой яркости. Если оно как-то сможет сделать это интеллектуально не просто умножая яркости на 0.8, а правя кривые и делая гистограмму более равномерное - то только лучше. Хотя и тупое умножение на 0.8 или на 1.2 подойдёт, даже если там светлые части засветятся, главное чтобы средняя яркость всего кадра была такая же.
>>67493
Потому что tblend интерполирует 2 кадра и дорисовывает промежуточные между ними, насколько я понял, больше нужно для увеличения фпс (по крайне мере такое было в примерах использования tblend)
А tmix именно что складывает (или проводит другие операции) над группами кадров - там было именно то, что мне нужно, и даже операцию сложения можно было указать, зачем что-то ещё искать?
Потому что tblend интерполирует 2 кадра и дорисовывает промежуточные между ними, насколько я понял, больше нужно для увеличения фпс (по крайне мере такое было в примерах использования tblend)
А tmix именно что складывает (или проводит другие операции) над группами кадров - там было именно то, что мне нужно, и даже операцию сложения можно было указать, зачем что-то ещё искать?
В моей карте есть аппаратный энкодер nvenc. Хочу использовать его при записи видео, тем самым разгрузив процессор и видеокарту для игр. Имеет ли смысл, или разница в производительности/качестве не велика?
Какие параметры использовать для записи видео?
Как скомпилировать FFmpeg с поддержкой nvenc? На сайте Nvidia пишут, что для этого нужны тяжёлые программы git и mingw, а для Visual Studio и вовсе нужен аккаунт майков, чтобы скачать. Сборка gyan.dev, пишут, поддерживает nvenc, но у меня ошибка:
а если использовать -hwaccel cuda, то качество будет супер-низким.
Помогите разобраться, аноны.
Какие параметры использовать для записи видео?
Как скомпилировать FFmpeg с поддержкой nvenc? На сайте Nvidia пишут, что для этого нужны тяжёлые программы git и mingw, а для Visual Studio и вовсе нужен аккаунт майков, чтобы скачать. Сборка gyan.dev, пишут, поддерживает nvenc, но у меня ошибка:
>Unrecognized hwaccel: nvenc.
>Supported hwaccels: cuda dxva2 qsv d3d11va
а если использовать -hwaccel cuda, то качество будет супер-низким.
Помогите разобраться, аноны.
>>68039
А тебе точно не подойдут готовые бинарники, которые уже его поддерживают? Если ты просто хочешь записывать видео, а не компилировать всякое - obs уже умеет писать через nvenc уже больше пяти лет точно.
Да, некоторые игры ты в 60 фпс другим способом и не запишешь толком. Но соотношения размера файла и качества очень плохое, это как h264 с ultrafast-пресетом
Ставь режим с постоянным параметром квантизация (-vcodec h264_nvenc -rc constqp -qp 20) с циферкой порядка 15-25, лучший режим для записи, так как вне зависимости от динамичности сцены и разрешения оно возьмёт битрейта сколько понадобится. Более продвинутый crf на видеокарте не работает, к сожалению.
>Как скомпилировать FFmpeg с поддержкой nvenc?
А тебе точно не подойдут готовые бинарники, которые уже его поддерживают? Если ты просто хочешь записывать видео, а не компилировать всякое - obs уже умеет писать через nvenc уже больше пяти лет точно.
>Имеет ли смысл
Да, некоторые игры ты в 60 фпс другим способом и не запишешь толком. Но соотношения размера файла и качества очень плохое, это как h264 с ultrafast-пресетом
>Какие параметры использовать для записи видео?
Ставь режим с постоянным параметром квантизация (-vcodec h264_nvenc -rc constqp -qp 20) с циферкой порядка 15-25, лучший режим для записи, так как вне зависимости от динамичности сцены и разрешения оно возьмёт битрейта сколько понадобится. Более продвинутый crf на видеокарте не работает, к сожалению.
>>68164
Не подойдут - как я писал выше, моя сборка не поддерживает hwaccel nvenc. Ещё не поддерживает filter:v scale_npp . То есть в сборке нет компонентов, отвечающих за работу с чипом записи в карте.
Грустно.
И ещё один вопрос - как записывать аудио вместе с видео? Через gdigrab звука нет. И что лучше - gdigrab или dshow?
>А тебе точно не подойдут готовые бинарники, которые уже его поддерживают?
Не подойдут - как я писал выше, моя сборка не поддерживает hwaccel nvenc. Ещё не поддерживает filter:v scale_npp . То есть в сборке нет компонентов, отвечающих за работу с чипом записи в карте.
>Но соотношения размера файла и качества очень плохое, это как h264 с ultrafast-пресетом
Грустно.
И ещё один вопрос - как записывать аудио вместе с видео? Через gdigrab звука нет. И что лучше - gdigrab или dshow?
>>68172
Говнина, болтающаяся в фоне. Оффлайн-программа, требующая логина, в принципе не достйна находиться где-либо, кроме как на помойке.
Говнина, болтающаяся в фоне. Оффлайн-программа, требующая логина, в принципе не достйна находиться где-либо, кроме как на помойке.
>>68182
+++
+++
>>68182
Ебать дебил
Она потребляет намного меньше ресурсов чем ffmpeg и obs при записи
>>68180
С помощью этой штуки можно собрать со всей этой нвидиа хуйней, я пробовал https://github.com/m-ab-s/media-autobuild_suite
Ебать дебил
Она потребляет намного меньше ресурсов чем ffmpeg и obs при записи
>>68180
С помощью этой штуки можно собрать со всей этой нвидиа хуйней, я пробовал https://github.com/m-ab-s/media-autobuild_suite
>>68172
Убогое нестабильное говно, которое ещё и дрочит диск постоянно, так как не может писать в оперативку.
Это тупо для домохозяек. Минимум опций, из коробки что-то там вроде как пишет и похуй. Проигрываю, когда всякие ИгРоВыЕ ЖуРнАлИсТы со стопгейма жалуются "ой, у меня вот почему-то нормально не захватывалась игра" и на футажах потоянно проблёскивает рабочий стол сквозь игру и постоянно видно значок записи, который вообще захватываться не должен.
Я уже не говорю, что с obs я пишу отдельно звук игры, винды, микрофона, voip, плеера. Причём сейчас для этого есть плагин, который позволяет перехватывать звук конкретного приложения из виндовской апишки, хотя я это делаю с помощью войсмитра.
>>68039
Ставишь OBS studio и выбираешь кодировщик NVENC? Что за изобретение велосипеда ты там устроил?
>Nvidia experience
Убогое нестабильное говно, которое ещё и дрочит диск постоянно, так как не может писать в оперативку.
Это тупо для домохозяек. Минимум опций, из коробки что-то там вроде как пишет и похуй. Проигрываю, когда всякие ИгРоВыЕ ЖуРнАлИсТы со стопгейма жалуются "ой, у меня вот почему-то нормально не захватывалась игра" и на футажах потоянно проблёскивает рабочий стол сквозь игру и постоянно видно значок записи, который вообще захватываться не должен.
Я уже не говорю, что с obs я пишу отдельно звук игры, винды, микрофона, voip, плеера. Причём сейчас для этого есть плагин, который позволяет перехватывать звук конкретного приложения из виндовской апишки, хотя я это делаю с помощью войсмитра.
>>68039
Ставишь OBS studio и выбираешь кодировщик NVENC? Что за изобретение велосипеда ты там устроил?
>>68335
Каких ресурсов ещё? Мы про те 3% процессора, которые потребляет OBS при записи нвенком или ты мои кудах ядра решил поберечь?
>Она потребляет намного меньше ресурсов чем ffmpeg и obs при записи
Каких ресурсов ещё? Мы про те 3% процессора, которые потребляет OBS при записи нвенком или ты мои кудах ядра решил поберечь?
>>68399
Долбоеб, у тебя 100 Гб оперативки?
Можно выбрать рамдиск
А так же домофона, уличной камеры, соседского жучка, первого канала и объявления электричек
>>68400
Обс отжирает 20-30% ГПУ при записи в отличии от нвидии
> Убогое нестабильное говно, которое ещё и дрочит диск постоянно, так как не может писать в оперативку.
Долбоеб, у тебя 100 Гб оперативки?
Можно выбрать рамдиск
> Я уже не говорю, что с obs я пишу отдельно звук игры, винды, микрофона, voip, плеера. Причём сейчас для этого есть плагин, который позволяет перехватывать звук конкретного приложения из виндовской апишки, хотя я это делаю с помощью войсмитра.
А так же домофона, уличной камеры, соседского жучка, первого канала и объявления электричек
>>68400
Обс отжирает 20-30% ГПУ при записи в отличии от нвидии
>>68510
Нет. Он просто верный подсос невидии.
Нет. Он просто верный подсос невидии.
>>68461
Да.
Нет, точно так же. Затестил сейчас. Диапазон точно такой же. Кадется у нвидии в среднем на пару процентов меньше, но это в рамках погрешности.
>Обс отжирает 20-30%
Да.
>в отличии от нвидии
Нет, точно так же. Затестил сейчас. Диапазон точно такой же. Кадется у нвидии в среднем на пару процентов меньше, но это в рамках погрешности.
>>68399
Оно научилось? Подскажи как такое включить?
>>68461
А какой у тебя битрейт? 20к? 1 гб всё ещё хватит на 5ять с лишним минут видео.
Это очень странно, в чём смысл видеокартовского энкодера, если в одной программе оно потребляет меньше ресурсов чем в другой?
Ещё как вариант там пресет nvenc стоит самый плохой и риалтаймовый, это и оправдывает пару процентов...
Ну и счётчики gpu врут - ты запустишь одну программу, где рисуется два квадрата двухмерных - и это съест 20-30 процентов gpu, потому что оно не может корректно определить нагрузку на себя.
>что с obs я пишу отдельно звук игры
Оно научилось? Подскажи как такое включить?
>>68461
>Долбоеб, у тебя 100 Гб оперативки?
А какой у тебя битрейт? 20к? 1 гб всё ещё хватит на 5ять с лишним минут видео.
>Обс отжирает 20-30% ГПУ при записи в отличии от нвидии
Это очень странно, в чём смысл видеокартовского энкодера, если в одной программе оно потребляет меньше ресурсов чем в другой?
Ещё как вариант там пресет nvenc стоит самый плохой и риалтаймовый, это и оправдывает пару процентов...
Ну и счётчики gpu врут - ты запустишь одну программу, где рисуется два квадрата двухмерных - и это съест 20-30 процентов gpu, потому что оно не может корректно определить нагрузку на себя.
>>68629
В том что обс делает дополнительные операции, он ещё рисует сцену чтобы можно было добавлять оверлеи и другие штуки
50 мегабит нвидиа рекомендует для обычного качества 1080p
> Это очень странно, в чём смысл видеокартовского энкодера, если в одной программе оно потребляет меньше ресурсов чем в другой?
В том что обс делает дополнительные операции, он ещё рисует сцену чтобы можно было добавлять оверлеи и другие штуки
> А какой у тебя битрейт? 20к? 1 гб всё ещё хватит на 5ять с лишним минут видео.
50 мегабит нвидиа рекомендует для обычного качества 1080p
>>68629
https://obsproject.com/forum/resources/win-capture-audio.1338/
Но я делаю иначе. У меня стоит voicemeeter. Он добавляет в систему три виртуальных аудиоустройства и микширует с них звук уже на реальное физическое. Программы разные вывожу на разные устройства и пишу их. Но, если нужна только запись, то плагина хватит.
>>68766
О нет! Что же делать? Может писать на диск в таком случае? В контейнер mkv, потому что мп4 при некорректном сохранении тебе ручкой помашет. Можно в mkv в хуитке от нвидиа сохранять?
>>68765
Не рекомендует, а не позволяет поставить больше. Не говоря уже об отсутствии cqp.
>Оно научилось? Подскажи как такое включить?
https://obsproject.com/forum/resources/win-capture-audio.1338/
Но я делаю иначе. У меня стоит voicemeeter. Он добавляет в систему три виртуальных аудиоустройства и микширует с них звук уже на реальное физическое. Программы разные вывожу на разные устройства и пишу их. Но, если нужна только запись, то плагина хватит.
>>68766
О нет! Что же делать? Может писать на диск в таком случае? В контейнер mkv, потому что мп4 при некорректном сохранении тебе ручкой помашет. Можно в mkv в хуитке от нвидиа сохранять?
>>68765
>50 мегабит нвидиа рекомендует для обычного качества 1080p
Не рекомендует, а не позволяет поставить больше. Не говоря уже об отсутствии cqp.
>>68765
Это абсолютный оверкилл даже для шутера со вращающимися сценами постоянными. Если про программный h264 речь.
И я хочу режим по типу crf - с постоянным качеством, который адаптивно подстроит битрейт под сложность сцены, фпс и размер кадра. Постоянный битрейт нужен только для стримов, где нужен примерно равный битрейт, чтобы не было буферизаций и поток данных был ожидаемый. Хотя по факту на тот же твитч можно стримить в crf-режиме с переменным битрейтом, и всё работает без особых проблем. По крайне мере работало 2 года назад.
>>68776
А дополнительной задержки в 50 мс условных не возникает?
>50 мегабит нвидиа рекомендует для обычного качества 1080p
Это абсолютный оверкилл даже для шутера со вращающимися сценами постоянными. Если про программный h264 речь.
И я хочу режим по типу crf - с постоянным качеством, который адаптивно подстроит битрейт под сложность сцены, фпс и размер кадра. Постоянный битрейт нужен только для стримов, где нужен примерно равный битрейт, чтобы не было буферизаций и поток данных был ожидаемый. Хотя по факту на тот же твитч можно стримить в crf-режиме с переменным битрейтом, и всё работает без особых проблем. По крайне мере работало 2 года назад.
>>68776
>Он добавляет в систему три виртуальных аудиоустройства
А дополнительной задержки в 50 мс условных не возникает?
>>68798
Возникает задержка, не помню насколько большая. Писал в обс микрофон напрямую и на выходе войсмитра, потом в видеоредакторе смотрел дорожки. Задержка не большая, но мониторинг себя сделать не получится. Хотя его никак через винду не сделаешь. Если на твоей карте есть ASIO (настоящий), то задержки будут ниже.
Это для пердоликов и шизиков. Если задача только писать звук на разные дорожки, то всё что нужно это обс+плагин.
Какой програмный, если мы тут рендер на гпу обсуждаем?
CQP в obs. Это не crf, но с задачей справляется.
>А дополнительной задержки в 50 мс условных не возникает?
Возникает задержка, не помню насколько большая. Писал в обс микрофон напрямую и на выходе войсмитра, потом в видеоредакторе смотрел дорожки. Задержка не большая, но мониторинг себя сделать не получится. Хотя его никак через винду не сделаешь. Если на твоей карте есть ASIO (настоящий), то задержки будут ниже.
Это для пердоликов и шизиков. Если задача только писать звук на разные дорожки, то всё что нужно это обс+плагин.
>Это абсолютный оверкилл даже для шутера со вращающимися сценами постоянными. Если про программный h264 речь.
Какой програмный, если мы тут рендер на гпу обсуждаем?
>И я хочу режим по типу crf
CQP в obs. Это не crf, но с задачей справляется.
>>68039
Я тебе скинуть могу, либо используй ffmpeg media suite он сам всё соберет, ты только выбери галочки, только долговато еще.
> Как скомпилировать FFmpeg с поддержкой nvenc?
Я тебе скинуть могу, либо используй ffmpeg media suite он сам всё соберет, ты только выбери галочки, только долговато еще.
>>68399
А какой плагин то юзал? Я просто пердолю через воисмитер тоже, но там ведь самая минимальная задержка по всем каналам у меня получилась 480мс. Довольно много по звуку задержка.
> Причём сейчас для этого есть плагин, который позволяет перехватывать звук конкретного приложения из виндовской апишки, хотя я это делаю с помощью войсмитра
А какой плагин то юзал? Я просто пердолю через воисмитер тоже, но там ведь самая минимальная задержка по всем каналам у меня получилась 480мс. Довольно много по звуку задержка.
>>68164
Хреню не неси людям тут. Давно обсудили, что качества уровня x264 ~medium-fast, на высоких битрейтах так тем более пох.
> Да, некоторые игры ты в 60 фпс другим способом и не запишешь толком. Но соотношения размера файла и качества очень плохое, это как h264 с ultrafast-пресетом
Хреню не неси людям тут. Давно обсудили, что качества уровня x264 ~medium-fast, на высоких битрейтах так тем более пох.
еще вы забываете, что фирменная технология нвидия по захвату экрана, который качественный и не забирает фпс вообще есть только в geforce experience на винде. На линукс для обс его запердолили obs-nvfbc. Я у разраба спршивал насчет винды, он отвечал "ряя у вас есть в geforce experience". Ну типичный красноглазик, жадные.
Вот и получается, что обс на винде использует стандартные апи, которые фпс жрут.
Еще по дефолту в GFN стоят хорошие высокие настройки качества с достаточно хорошим весом, зато четкая картинка, когда он не тупит. Настройки вроде только через реестр можно сменить.
Поэтому пишу через nvenc obs в 12-14к битрейта для фуллхд. 20мин видео апекс с кучей движения всего 1 гиг весит, на уровне или чуть выше ютуба.
Вот и получается, что обс на винде использует стандартные апи, которые фпс жрут.
Еще по дефолту в GFN стоят хорошие высокие настройки качества с достаточно хорошим весом, зато четкая картинка, когда он не тупит. Настройки вроде только через реестр можно сменить.
Поэтому пишу через nvenc obs в 12-14к битрейта для фуллхд. 20мин видео апекс с кучей движения всего 1 гиг весит, на уровне или чуть выше ютуба.
>>70287
Это вообще не уровень Ютуба лол
Это вообще не уровень Ютуба лол
>>70287
Пиздабол.
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
>технология нвидия по захвату экрана, который качественный и не забирает фпс вообще есть только в 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
>>70287
Это все лосслесс vfw-кодаки делают, тот же lagarith. Шизище...
> который качественный и не забирает фпс вообще
Это все лосслесс vfw-кодаки делают, тот же lagarith. Шизище...
>>70389
Так же OBS:
https://www.nvidia.com/en-us/geforce/guides/broadcasting-guide/
Так же OBS:
https://www.nvidia.com/en-us/geforce/guides/broadcasting-guide/
>Encoder: Hardware (NVENC).
>>44406 (OP)
Поясните, есть ли открытые легкие кодеки, которые не теряют качество? Думаю, может весь зоопарк формат своих домашних видео привести к единобразию и место уменьшить, или без потери качество не удастся сделать?
Поясните, есть ли открытые легкие кодеки, которые не теряют качество? Думаю, может весь зоопарк формат своих домашних видео привести к единобразию и место уменьшить, или без потери качество не удастся сделать?
>>70389
Ну и нахуя ты мне энкодинг nvenc притащил, дибилоид. В слова хоть вчитывайся.
Ну и нахуя ты мне энкодинг nvenc притащил, дибилоид. В слова хоть вчитывайся.
>>70390
И что это? К чему это? Кто из нас шиз-то?
>Это все лосслесс vfw-кодаки делают, тот же lagarith. Шизище...
И что это? К чему это? Кто из нас шиз-то?
в AV1 -preset 6 - что означает шесть?
количество физических ядер или количество потоков (логических процессоров)?
-preset 0 - качественнее жмёт или качественнее картинку не портит
как сделать, чтобы не было мыла?
количество физических ядер или количество потоков (логических процессоров)?
-preset 0 - качественнее жмёт или качественнее картинку не портит
как сделать, чтобы не было мыла?
47 Кб, 1853x347>>71049
Не имеет к количеству ядер никакого отношения. При больших значениях он жмёт быстрее, но хуже, и наоборот, при маленьких значениях жмёт дольше, но лучше.
Не имеет к количеству ядер никакого отношения. При больших значениях он жмёт быстрее, но хуже, и наоборот, при маленьких значениях жмёт дольше, но лучше.
>>71055
а кто-то пробовал жать с пресетами 1-3. как долго?
а кто-то пробовал жать с пресетами 1-3. как долго?
А зачем нужен Rec.2020? Его же только топовые лазерные проекторы с тремя лазерами могут отобразить. Светодиоды даже с квантовыми точками выше DCI P3 не способны прыгнуть.
>>71220
ну я в Davicni вижу настройку этой штуки. там есть 709, 2020, вроде 601
что из этого выбирать, если сорц - ролики из порнолаба?
ну я в Davicni вижу настройку этой штуки. там есть 709, 2020, вроде 601
что из этого выбирать, если сорц - ролики из порнолаба?
Пришлось удалить -svtav1-params tune=0:irefresh-type=1.
С этими параметрами не начинался кодинг
С этими параметрами не начинался кодинг
133 Кб, 400x425>>71195
Это тоже самое что просто увеличить разрешение у картинки с низким разрешением. Конвертнув в 2020 цвета же останутся от 709
Это тоже самое что просто увеличить разрешение у картинки с низким разрешением. Конвертнув в 2020 цвета же останутся от 709
>>71291
Нужно существенно повысить глубину цвета что-бы прежние цвета сохранились без искажений.
Нужно существенно повысить глубину цвета что-бы прежние цвета сохранились без искажений.
118 Кб, 970x690Подскажите как конвертнуть аудио дорожку DTS HD MA в простой DTS.
Есть нормальные способы сжать видос кроме ffmpeg? Пиздец гемор. Не хватало учиться программировать чтобы видос сжать
>>71770
Что это значит?
Что это значит?
>>71742
В кадрах.
В кадрах.
можно ли с помощью ffmpeg определить наличие soft pulldown(если я это правильно называю), ну и как в таком случае перекодировать видео чтобы ffmpeg на добавлял дублирующие кадры из 23.976 в 29.97 а оставил искодный фпс?
>>71046
Пока нового аппаратного кодека не запилят, либо пока h266 не будет таким же быстрым как h264 и лучше качество, значит ненужны.
Пока нового аппаратного кодека не запилят, либо пока h266 не будет таким же быстрым как h264 и лучше качество, значит ненужны.
>>71225
Это цветовое пространство. 709 для hd fullhd, 2020 4k, 601 вроде всё что ниже hd.
> там есть 709, 2020, вроде 601
Это цветовое пространство. 709 для hd fullhd, 2020 4k, 601 вроде всё что ниже hd.
>>72394
аппаратный не раньше 5000 серии geforce
аппаратный не раньше 5000 серии geforce
212 Кб, 1080x1679я не одупляю что он хочет он меня, на тел скачал мобильный ффмпог, все работало норм потом вылезло это,
>>73825
Запускаешь его конвертить длинный файл, открываешь процесс ffmpeg и смотришь параметры командной строки, при помощи Process Explorer или Process Hacker. Потом просто запускаешь ffmpeg отдельно с теми же параметрами.
>какой-то конвертер на базе ffmpeg кодирует без проблем
Запускаешь его конвертить длинный файл, открываешь процесс ffmpeg и смотришь параметры командной строки, при помощи Process Explorer или Process Hacker. Потом просто запускаешь ffmpeg отдельно с теми же параметрами.
>>73808
Пользовался бы ты консольным ffmpeg, он бы тебе выдал что-то вроде invalid option "-ab", после чего ты пошел бы гуглить мануалы и узнал бы что этот параметр пишется как -b:a.
> ab 128k
> пук пук у нас ошибка
Пользовался бы ты консольным ffmpeg, он бы тебе выдал что-то вроде invalid option "-ab", после чего ты пошел бы гуглить мануалы и узнал бы что этот параметр пишется как -b:a.
26 Кб, 1060x136скачал какой то софт для апскейла фпс так как ффмпег по чайной ложке кодирует даже проц и видюху не нагружает, называется butterflow и он тоже не работаит
>>74430
В интерполяцию по векторам движения как это делает -vf minterpolate? Я пробовал запустить mpv с таким фильтром. Скорость рендеринга кадров делает невозможным просмотр видео в реалтайме, поэтому без кодирования тут не обойтись.
В интерполяцию по векторам движения как это делает -vf minterpolate? Я пробовал запустить mpv с таким фильтром. Скорость рендеринга кадров делает невозможным просмотр видео в реалтайме, поэтому без кодирования тут не обойтись.
почему бывает при кодировании видео в строке появляется dup=1, с чего вдруг кадр продублировался?
>>74348
Может как хочешь писать, дэбил.
Может как хочешь писать, дэбил.
3,9 Мб, mp4,720x720, 0:15
>>74854
Спасибо лучший
Спасибо лучший
>>74352
Если тупо аниме смотреть в плеере, то SVP. Еще есть старые interframe тот же SVP, и также старый framerateconverter. Сейчас есть RIFE, который во flowframes есть, лучший на сегодня, еще и быстрый пипец, правда фиксить мануально надо. Либо через avisynth/vapoursynth пердолить, либо в hybrid от selur. Раньше был еще супер медленный DAIN. Другие внимания не стоят пока.
Если тупо аниме смотреть в плеере, то SVP. Еще есть старые interframe тот же SVP, и также старый framerateconverter. Сейчас есть RIFE, который во flowframes есть, лучший на сегодня, еще и быстрый пипец, правда фиксить мануально надо. Либо через avisynth/vapoursynth пердолить, либо в hybrid от selur. Раньше был еще супер медленный DAIN. Другие внимания не стоят пока.
>>71050
Как это не нужен? Тот же aomenc --cpu-used=5 сравним с медленными пресетами x265, как по времени кодирования, так и по качеству картинки.
А вот rav1e вместе с svt-av1 не нужны, да.
Как это не нужен? Тот же aomenc --cpu-used=5 сравним с медленными пресетами x265, как по времени кодирования, так и по качеству картинки.
А вот rav1e вместе с svt-av1 не нужны, да.
>>75256
Не стоит ориентироваться на vmaf, он даёт больше баллов мыльной картинке. Aom точно будет хуже и медленнее x265, а вот svt-av1 лучше
Не стоит ориентироваться на vmaf, он даёт больше баллов мыльной картинке. Aom точно будет хуже и медленнее x265, а вот svt-av1 лучше
Как настроить обс чтобы с нормальным качеством был маленький размер? Получается только размытое говно со 100 мб за 1 минуту
>>76301
Напиши характеристики компьютера
Напиши характеристики компьютера
>>76576
Да ничем. JPEG это кодек сжатия с потерями. JPEG Interchange File Format это формат файла для храниния данных закодированных кодеком JPEG. .jpg это расширение файла ещё с досовских времен, когда древняя файловая система FAT не могла хранить больше трёх символов в расширении.
Да ничем. JPEG это кодек сжатия с потерями. JPEG Interchange File Format это формат файла для храниния данных закодированных кодеком JPEG. .jpg это расширение файла ещё с досовских времен, когда древняя файловая система FAT не могла хранить больше трёх символов в расширении.
8 Кб, 569x37>>76651
Ты читать не умеешь? Или отсебятину пишешь?
Или ты один из тех кто жмёт в джипеги все пикчи без разбору?
Ты читать не умеешь? Или отсебятину пишешь?
Или ты один из тех кто жмёт в джипеги все пикчи без разбору?
>>76645
Спасибо.
Спасибо.
Что в выводе ffmepg-а значит Duration: ... start: 600.120000 ?
22 Кб, 828x427>>44406 (OP)
Знатоки, есть вопрос.
Возможно ли каким-либо образом распараллелить кодирование webm vp9? Быть может кто-то просто знает возможно ли это в целом, пусть даже технической реализации нет Меня достало, что, когда я хочу получить высшее качество с наименьшим размером, я должен сидеть и смотреть час как у меня одно ядро в сотку долбится.
Знатоки, есть вопрос.
Возможно ли каким-либо образом распараллелить кодирование webm vp9? Быть может кто-то просто знает возможно ли это в целом, пусть даже технической реализации нет Меня достало, что, когда я хочу получить высшее качество с наименьшим размером, я должен сидеть и смотреть час как у меня одно ядро в сотку долбится.
>>77306
Лучшее сжатие и распараллеливание это в принципе противоположности. Выбери 1 стул.
Лучшее сжатие и распараллеливание это в принципе противоположности. Выбери 1 стул.
>>77306
Можно разрезать его на куски, с помощью хохляцкой перемоги av1an. Будут нагружены все ядра. Кстати не ставь quality best
А вообще кодируй в svt-av1, выйдет быстрее и качественнее, и так же поддерживается в браузерах.
Можно разрезать его на куски, с помощью хохляцкой перемоги av1an. Будут нагружены все ядра. Кстати не ставь quality best
А вообще кодируй в svt-av1, выйдет быстрее и качественнее, и так же поддерживается в браузерах.
>>76301
Нифига ты офигел. 100 ему много за минуту. Перекодируй потом если тебе прям малый размер нужен после записи. Я вообще настроил прямо в притык и то чуть мыльно за 20 минут примерно 1 гиг.
> 100 мб за 1 минуту
Нифига ты офигел. 100 ему много за минуту. Перекодируй потом если тебе прям малый размер нужен после записи. Я вообще настроил прямо в притык и то чуть мыльно за 20 минут примерно 1 гиг.
>>77306
Была прога какая-то, тоже на куски режет, только через жопу работать стала почему-то.
https://github.com/Alkl58/NotEnoughAV1Encodes
Была прога какая-то, тоже на куски режет, только через жопу работать стала почему-то.
https://github.com/Alkl58/NotEnoughAV1Encodes
>>75270
Базаришь? Вот тебе 4 картинки, скажи где тут aom, а где svt?
> Aom точно будет хуже и медленнее x265, а вот svt-av1 лучше
Базаришь? Вот тебе 4 картинки, скажи где тут aom, а где svt?
>>77964
Потому что 320 это максимальный битрейт для MP3.
Потому что 320 это максимальный битрейт для MP3.
1,5 Мб, 544x494>>77951
Но ведь одинаково говно на картинках, можно кодек покачественнее посмотреть?
Но ведь одинаково говно на картинках, можно кодек покачественнее посмотреть?
>>77964
Дауны потому что, дефолтом разработки и развития все последние версии в lame давным давно стал vbr v0, на cbr хуй клали еще с нулевых и правильно. vbr - Стандарт сука!
Дауны потому что, дефолтом разработки и развития все последние версии в lame давным давно стал vbr v0, на cbr хуй клали еще с нулевых и правильно. vbr - Стандарт сука!
>>78010
Bandcamp кстати именно его и предлагает дефолтом, всегда! но для уточек держит и cbr, бгг.
Bandcamp кстати именно его и предлагает дефолтом, всегда! но для уточек держит и cbr, бгг.
Но только он не нужен, я лучше aac выберу в виду его нетребовательности к ресурсам и скорости. А если очень хочется повыёбываться, то lossy tak или lossy flac - no chances для всех остальных лосси)). Плюс киллер фича)) >>51250
>>77951
По одной какой-то абстрактной картинке ничего нельзя сказать. Кодеки предназначены для сжатия видео снятых в реальной жизни
По одной какой-то абстрактной картинке ничего нельзя сказать. Кодеки предназначены для сжатия видео снятых в реальной жизни
>>78036
Да, но режим cbr занимает лишнее место, даже если звук на самом деле может весить меньше
Да, но режим cbr занимает лишнее место, даже если звук на самом деле может весить меньше
>>78121
Не нравиться Opus, юзай AAC, или Vorbis если поддержка есть. Просто маяться с конвертацией в AAC под Linux мне не очень хочется. А с учётом того что Opus жмёт даже лучше обеих кодеков, ну в общем совсем не хочется.
Не нравиться Opus, юзай AAC, или Vorbis если поддержка есть. Просто маяться с конвертацией в AAC под Linux мне не очень хочется. А с учётом того что Opus жмёт даже лучше обеих кодеков, ну в общем совсем не хочется.
Есть ли документация на русском? Понимаю, что это маразм, но нужно разобраться в некоторых вещах.
Есть ли тут человек, который готов помочь разобраться в некоторых вещах?
Есть ли тут человек, который готов помочь разобраться в некоторых вещах?
>>78639
От той, что есть понятнее не станет.
Ты с сажей в тред пришёл. Почему просто не написать интересующий вопрос?
> Есть ли документация на русском? Понимаю, что это маразм, но нужно разобраться в некоторых вещах
От той, что есть понятнее не станет.
> Есть ли тут человек, который готов помочь разобраться в некоторых вещах
Ты с сажей в тред пришёл. Почему просто не написать интересующий вопрос?
>>78639
Переводчик для кого придумали?
>Есть ли документация на русском? Понимаю, что это маразм, но нужно разобраться в некоторых вещах
Переводчик для кого придумали?
>>78782
Сажу выключить забыл.
В общем есть 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 видео. Нужно объединить в один файл, но аудио должно быть в разных потоках.
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, то он сам распределить последовательно?
>>78792
Давай по буквам, я такого не делал и не понимаю концепции, что с видео? У тебя 3 видео, ты их хочешь склеить в 1? Но чтобы к первой части полученного объединённого видео звук был на одной дорожке, ко второй части на второй и к третьей на 3?
Давай по буквам, я такого не делал и не понимаю концепции, что с видео? У тебя 3 видео, ты их хочешь склеить в 1? Но чтобы к первой части полученного объединённого видео звук был на одной дорожке, ко второй части на второй и к третьей на 3?
>>78802
Объедини виде отдельно, сделай 3 дорожки длинной с полученное видео, добавив пустоту в нужных местах, залей дорожки с помощью map, то что ты сейчас рожаешь выглядит не здорово.
Объедини виде отдельно, сделай 3 дорожки длинной с полученное видео, добавив пустоту в нужных местах, залей дорожки с помощью map, то что ты сейчас рожаешь выглядит не здорово.
21 Кб, 496x499>>78809
Ну видео так, если разрешение идентичное
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 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 срёт ошибками, если пытаешься сделать реверс и апад одновременно. Пользуйся.
>>78861
Или там не фреймы, не помню, в общем придётся приловчится, чтобы попасть в нужный тайминг.
> количество фреймов, когда начинается звуе
Или там не фреймы, не помню, в общем придётся приловчится, чтобы попасть в нужный тайминг.
>>78861
Здесь sortest не нужен из-за явного указания окончания тишины
> ffmpeg -i скленное видео -i дорожка 2 -af "apad=pad_len=количество фреймов, когда начинается звуе" -shortest
Здесь sortest не нужен из-за явного указания окончания тишины
>>78861
И вообще комманда похожа на говно, наверняка можно просто нажать apad и установить таймер -t в секундах(тишана от начала+длительность звуковой дорожки), вместо дебильного pad_len
> ffmpeg -i скленное видео -i дорожка 2 -af "apad=pad_len=количество фреймов, когда начинается звуе" -shortest -vn дорожка 2.1
И вообще комманда похожа на говно, наверняка можно просто нажать apad и установить таймер -t в секундах(тишана от начала+длительность звуковой дорожки), вместо дебильного pad_len
2 Мб, 640x376А я обратно в дурку, пока старшие не засмеяли и не принесли одну команду, которой это все делается
Не нашел тред по рендеру видосов, думаю эта тема смежная. Какие настройки пикать в vegas, чтобы весило мало и выглядело хорошо?
>>78861
Не пойму вот чего, откуда у тебя склеенное видео, когда 4.mp4 у тебя без звука?
>скленное видео
Не пойму вот чего, откуда у тебя склеенное видео, когда 4.mp4 у тебя без звука?
>>78926
А что не так? От него нужна только общая продолжительность, а звука в нём быть и не должно.
А что не так? От него нужна только общая продолжительность, а звука в нём быть и не должно.
>>78928
Я все равно пока не до конца это понимаю. Можешь расписать командами, если представить что у меня есть файл video1.mp4, video2 и video3
Я все равно пока не до конца это понимаю. Можешь расписать командами, если представить что у меня есть файл video1.mp4, video2 и video3
>>78956
Так там же и расписано командами, но ок
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
Так там же и расписано командами, но ок
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
809 Кб, mp4,1280x720, 0:06
>>78956
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 -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 -re -stream_loop -1 -i video1.mp4 -i audio1.mp3 -map 0:v -map 1:a -f flv rtmp://b.rtmp.youtube.com/live2/ключ
Когда аудио заканчивается, оно не стартует заново, а просто зависает. В консоли стрим типа идет, ошибок нет, а по факту стрим как-будто завис
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/ключ
Когда аудио заканчивается, оно не стартует заново, а просто зависает. В консоли стрим типа идет, ошибок нет, а по факту стрим как-будто завис
>>79027
Тебе надо чтобы все 3 звуковые дорожки были идентичной длинны с video4.mp4, с 1 и 3 всё ясно, со второй тебе нужно указать время первого фрагмента + время второго, чтобы получить тишину до начала второго фрагмента, а затем к полученному результату ещё добавить тишина с конца второго фрагмента по конец третьего, получив таким образом дорожку, состоящую из тишина + звуковая дорожка видео 2 + тишина до конца видео. Я не знаю как проще объяснить.
Тебе надо чтобы все 3 звуковые дорожки были идентичной длинны с video4.mp4, с 1 и 3 всё ясно, со второй тебе нужно указать время первого фрагмента + время второго, чтобы получить тишину до начала второго фрагмента, а затем к полученному результату ещё добавить тишина с конца второго фрагмента по конец третьего, получив таким образом дорожку, состоящую из тишина + звуковая дорожка видео 2 + тишина до конца видео. Я не знаю как проще объяснить.
>>79034
Я про вот эти значения -t. Откуда ты их взял?
>ffmpeg -hide_banner -i video1.mp4 -af "apad" -t 6.207 -vn -y audio1.mp4
Я про вот эти значения -t. Откуда ты их взял?
>>79036
Для каких целей тебе вообще такое странное видео понадобилось?
Для каких целей тебе вообще такое странное видео понадобилось?
>>79038
Я про то, что это в целом рандомные цифры для примера. Там я указываю время своего видео?
Я про то, что это в целом рандомные цифры для примера. Там я указываю время своего видео?
>>79044
Да
Да
>>79104
Вероятно ты пытаешься запихнуть в mp4 формат, который туда запихнуть нельзя.
Вероятно ты пытаешься запихнуть в mp4 формат, который туда запихнуть нельзя.
>>79187
Спасибо, помогло. Но, как оказалось, на одноядерном атлоне перекодировать видосы - гиблое дело. Он уже перегрелся, а перекодировано 2 минуты из 32.
Спасибо, помогло. Но, как оказалось, на одноядерном атлоне перекодировать видосы - гиблое дело. Он уже перегрелся, а перекодировано 2 минуты из 32.
У меня есть видео с каналами с аудиоканалами FL+FR+FC+LFE+BL+BR+DL+DR. Как мне из него вывести два видео с каналами 5.1 и стерео?
Анон, как в винде массово объединить видео и аудио? Условно видео_1.mp4, видео_2.mp4, видео_3.mp4 и такие же аудио 1-3.
Их просто склеить надо массово
Их просто склеить надо массово
>>79262
Тут больше вопрос, как мне связать видео_1 с аудио_1. Я не шарю, за написание скриптов
Тут больше вопрос, как мне связать видео_1 с аудио_1. Я не шарю, за написание скриптов
157 Кб, 850x1202Откуда ж вы такие новенькие ньюфаги то взялись, да ещё и тред найти смогли, а простенькая утилита вызывает столько вопросов.
>>79275
Да я знаю как склеить, я не понимаю, как мне это сделать массово. Чтобы video_1.mp4 склеить с audio_1.aac, video_2.mp4 с audio_2.aac и т.д.
Да я знаю как склеить, я не понимаю, как мне это сделать массово. Чтобы video_1.mp4 склеить с audio_1.aac, video_2.mp4 с audio_2.aac и т.д.
>>79276
Пусть просвещаются лучшим и мощнейшим инструментарием. ffmpeg лучший редактор, ffplay лучший плеер. Нодискасс.
Пусть просвещаются лучшим и мощнейшим инструментарием. ffmpeg лучший редактор, ffplay лучший плеер. Нодискасс.
6 Мб, 360x360>>79278
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! - КОНЕЦ
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! - КОНЕЦ
>>79293
Ну да, на что я надеялся, а [code] на абучане не пашет?[/code]
Ну да, на что я надеялся, а [code] на абучане не пашет?[/code]
Как этот парашный формат хдр, в котором высирают новые фильмы конвертировать в нормальный цвет, я просто в ахуе с это тусклой картинки, которую выдает после конвертации любой рекодер, и от тусклых скриншотов, которые делает любой плеер.
И ведь нигде нет фильмов в высоком разрешении с нормальной картинкой. Везде если выше 1080 - только этот мусор.
И ведь нигде нет фильмов в высоком разрешении с нормальной картинкой. Везде если выше 1080 - только этот мусор.
>>79547
Тебе не кажется такое сочетание странным? Ты либо ОС обнови, либо 1080p моник на место верни.
> Windows 7
> Ultra HD моник
Тебе не кажется такое сочетание странным? Ты либо ОС обнови, либо 1080p моник на место верни.
>>79561
Не так странно, как люди в s до сих пор обращающие внимание на юзерагент. Ты новенький?
Не так странно, как люди в s до сих пор обращающие внимание на юзерагент. Ты новенький?
>>79599
Это корейский?
Это корейский?
>>79505
Для ОБЫЧНОГО видео, не для аниме или что там ещё бывает. Мне цифра нужна, 25, 30, 35.
Для ОБЫЧНОГО видео, не для аниме или что там ещё бывает. Мне цифра нужна, 25, 30, 35.
35 Кб, 640x529> 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
Вы шизофреники, в курсе?
>>79646
Проблема в том, что на семёрке сидят либо деды-пердеды, не признающие десятку, либо нищеброды на некропекарнях. Притом первое не исключает второго.
А ещё проблема в том, что для гейминга в 2K или даже 4K нужно современное железо, которое нищебродам на некропеках недоступно. Ну и наконец, даже у десяточки с масштабированием интерфейса дела говорят не очень. А про семёрку я вообще молчу.
Проблема в том, что на семёрке сидят либо деды-пердеды, не признающие десятку, либо нищеброды на некропекарнях. Притом первое не исключает второго.
А ещё проблема в том, что для гейминга в 2K или даже 4K нужно современное железо, которое нищебродам на некропеках недоступно. Ну и наконец, даже у десяточки с масштабированием интерфейса дела говорят не очень. А про семёрку я вообще молчу.
120 Кб, 518x604> Chromium based
> Firefox based
> пыльмун не бейсед
>>79608
Обычного видео не существует, не выдумывай.
Обычного видео не существует, не выдумывай.
>>79474
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
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
>>79788
Перед аудио стрим луп допиши
Перед аудио стрим луп допиши
>>78013
Качество звука будет не ощутимо от lossless? А места сколько займёт? Что по тегам?
Научи меня кодировать в них.
>А если очень хочется повыёбываться, то lossy tak или lossy flac
Качество звука будет не ощутимо от lossless? А места сколько займёт? Что по тегам?
Научи меня кодировать в них.
>>77964
Рациональнее спрашивать почему MP3 всё ещё жив. Vorbis и AAC с поставленной задачей справляются не хуже, а проблема аппаратной совместимости стала куда менее актуальной.
Рациональнее спрашивать почему MP3 всё ещё жив. Vorbis и AAC с поставленной задачей справляются не хуже, а проблема аппаратной совместимости стала куда менее актуальной.
30 Кб, 483x466>>80424
Потому что у меня плеер за 30 рублей.
Потому что у меня плеер за 30 рублей.
>>44406 (OP)
Нужно через bat-скрипт сыграть частоту 60 гц на протяжении одной секунды с громкостью программно увеличенной на 15 Дб. Какую команду ffplay/ffmpeg использовать?
Нужно через bat-скрипт сыграть частоту 60 гц на протяжении одной секунды с громкостью программно увеличенной на 15 Дб. Какую команду ffplay/ffmpeg использовать?
>>81028
Я на QBasic такое в школе писал, на пару строк будет, а ffmpeg для этого наверно не очень подходит.
Я на QBasic такое в школе писал, на пару строк будет, а ffmpeg для этого наверно не очень подходит.
>>81037
А вот в 2022 супертехнологии так не позволяют. Нельзя такого написать, потому что в звуковых картах больше нет синтераторов. Нужен звук - сначала сгенери wav-ку с ним, а потом её проигрывай. Дико уебищно, да? Прогресс, жри, сука.
>Я на QBasic такое в школе писал, на пару строк будет
А вот в 2022 супертехнологии так не позволяют. Нельзя такого написать, потому что в звуковых картах больше нет синтераторов. Нужен звук - сначала сгенери wav-ку с ним, а потом её проигрывай. Дико уебищно, да? Прогресс, жри, сука.
>>81462
А что ты там искать планируешь?
Сборки: https://www.animmouse.com/p/ffmpeg-binaries/
Сырцы: https://github.com/FFmpeg/FFmpeg
А что ты там искать планируешь?
Сборки: https://www.animmouse.com/p/ffmpeg-binaries/
Сырцы: https://github.com/FFmpeg/FFmpeg
>>81475
Что это нонейм? В официальном источнике только две ссылки:
1. https://www.gyan.dev/ffmpeg/builds/
2. https://github.com/BtbN/FFmpeg-Builds/releases
Что это нонейм? В официальном источнике только две ссылки:
1. https://www.gyan.dev/ffmpeg/builds/
2. https://github.com/BtbN/FFmpeg-Builds/releases
>>81475
Изначально хотел сынтерполировать 29.97 фпс в 60 через rife, но после непосредственно разжатия видео на кадры и интерполяции синхронизация аудио/видео по пизде пошла, видео раньше примерно на 70 мс. Мб pts где-то проебался, не ебу. Хотел про параметры vsync почитать, а тут вот в архив лезть пришлось.
Изначально хотел сынтерполировать 29.97 фпс в 60 через rife, но после непосредственно разжатия видео на кадры и интерполяции синхронизация аудио/видео по пизде пошла, видео раньше примерно на 70 мс. Мб pts где-то проебался, не ебу. Хотел про параметры vsync почитать, а тут вот в архив лезть пришлось.
>>81479
И еще после сборки всего этого в один файл, конечно же.
>после непосредственно разжатия видео на кадры и интерполяции
И еще после сборки всего этого в один файл, конечно же.
>>81477
У FFMpeg нет официальных сборок, по известным всем, кроме долбоёбов причинам. Вышеприведённые сборки такая же васянщина.
> Что это нонейм? В официальном источнике только две ссылки:
У FFMpeg нет официальных сборок, по известным всем, кроме долбоёбов причинам. Вышеприведённые сборки такая же васянщина.
544 Кб, 1055x580>>81479
Короче оказалось, что 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
В пизду, спать пойду.
Короче оказалось, что 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
В пизду, спать пойду.
45 Кб, 1273x496>>81492
Тем не менее, в официальном источнике того васяна нет. Тут как с KeePass. Есть васяны, которые одобрены на официальном уровне непосредственно разработчиком/разработчиками оригинала, раз позволили представлять свой проект на сайте. И к слову, BtbN оказался не такой уж и васян, раз на нём держится репозиторий в GitHub с 30к звёздами.
Тем не менее, в официальном источнике того васяна нет. Тут как с KeePass. Есть васяны, которые одобрены на официальном уровне непосредственно разработчиком/разработчиками оригинала, раз позволили представлять свой проект на сайте. И к слову, BtbN оказался не такой уж и васян, раз на нём держится репозиторий в GitHub с 30к звёздами.
>>81497
Сборка BtbN кал без fdkaac. На этом можно подытожить её ценность.
Сборка BtbN кал без fdkaac. На этом можно подытожить её ценность.
>>81493
Потому что с -c:copy ffmpeg может резать только по ключевым кадрам. Хочешь, чтобы порезал ровно - перекодируй.
Потому что с -c:copy ffmpeg может резать только по ключевым кадрам. Хочешь, чтобы порезал ровно - перекодируй.
Есть куча фоток со свадьбы, 25гб джипегов в каком-то охуевшем разрешении.
Подскажите во что лучше пережать и в какое разрешение будет адекватно, учитывая околонулевую художественную ценность фото. Мама хочет отвезти бабушке показать, но 25гб это перебор.
Вообще охуел, что камеры в жпг снимают.
Подскажите во что лучше пережать и в какое разрешение будет адекватно, учитывая околонулевую художественную ценность фото. Мама хочет отвезти бабушке показать, но 25гб это перебор.
Вообще охуел, что камеры в жпг снимают.
>>81532
Оно избыточно в данном случае имхо. Это просто фотографии людей на свадьбе, там не надо 4000х3000.
>>81531
А телефон изкаробки прожуёт его? Мама поедет в пердь и с телефона бабушке покажет. Сторонние просмотрщики ставить мало смысла - мама, ожидаемо, не очень с техникой, там типичная история с яркостью 200, 9999 вкладов в браузере и пуши со всех посещённых сайтов.
Оно избыточно в данном случае имхо. Это просто фотографии людей на свадьбе, там не надо 4000х3000.
>>81531
А телефон изкаробки прожуёт его? Мама поедет в пердь и с телефона бабушке покажет. Сторонние просмотрщики ставить мало смысла - мама, ожидаемо, не очень с техникой, там типичная история с яркостью 200, 9999 вкладов в браузере и пуши со всех посещённых сайтов.
>>81534
Нет, не избыточное, не надо ничего шакалить блять! А то хочешь приблизить и всё в пикселях
Не прожуёт, надо ставить что-то стороннее.
Нет, не избыточное, не надо ничего шакалить блять! А то хочешь приблизить и всё в пикселях
Не прожуёт, надо ставить что-то стороннее.
>>81541
Можно любое качество поставить, хоть в гигабайт
Можно любое качество поставить, хоть в гигабайт
400 Кб, 2000x2000ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
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 (М)
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
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 (
М)>>81493
Качаешь авидемукс, ищешь по ключевым i-frame, там есть опция и режешь.
Качаешь авидемукс, ищешь по ключевым i-frame, там есть опция и режешь.
Тред утонул или удален.
Это копия, сохраненная 5 августа 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 5 августа 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.