Этого треда уже нет.
Это копия, сохраненная 28 января 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 28 января 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
400 Кб, 2000x2000FFmpeg и общий кодирования видео тред №8
В прошлый раз мы весь тред обсуждали тонкости сжатия и разбирали команды.
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 (принимается критика, её было много в треде №6): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html (
М)
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html (М)
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html (М)
Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html (М)
Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html (М)
Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html (М)
Тред №6: https://2ch.hk/s/res/3144406.html (М)
Тред №7: https://2ch.hk/s/res/3181555.html (М)
В прошлый раз мы весь тред обсуждали тонкости сжатия и разбирали команды.
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 (принимается критика, её было много в треде №6): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html (
М)Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html (
М)Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html (
М)Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html (
М)Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html (
М)Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html (
М)Тред №6: https://2ch.hk/s/res/3144406.html (
М)Тред №7: https://2ch.hk/s/res/3181555.html (
М)>>05465
Шапку читать.
Шапку читать.
>>3205329 →
Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.
Не гармоник, а коэффициентов преобразования.
Давным давно в далёкой-далёкой галактике был MPEG-2, у которого в профиле Main на уровне Main была опция, позволяющая представлять с большей точностью (10 бит) только коэффициент постоянной составляющей для блока 8×8. Входные и выходные данные при этом представлялись 8-разрядным числом (целым или дробным с фиксированным разделителем, что суть одно и то же). На глаз это должно было повышать качество воспроизводимой последовательности. Рассуждения примерно такие:
- коэффициент постоянной составляющей является результатом вычислений и при его округлении в процессе нормирования при ДКП имеется искажение, дисперсия которого с точностью до постоянного множителя является энергией или мощностью сигнала искажения; так если цена младшего значащего разряда меньше на два двоичных порядка (в 4 раза), то дисперсия, энергия и мощность сигнала искажения уменьшаются в 16 раз;
- уменьшение мощности искажений при вычислении прямого ДКП, обратного ДКП и квантовании коэффициентов ДКП позволит получить более точное восстановление постоянных составляющие в блоках воспроизводимого сигнала, что сделает менее заметной на глаз разность в яркости смежных блоков на тех участках изображение, где эта разность не замаскирована высокочастотными составляющими (например, градиенты большой площади, изображения неба с малым количеством облаков и т. д.);
- в процессе подбора параметра квантования у кодера появляется возможность более точно решить оптимизационную задачу уже при двухкритериальной целевой функции — СКО-подобный (энергетический) показатель искажений восстановленного сигнала и количество информации для представления требуемых элементов в закодированном потоке.
Более обобщим способом для современных кодеров по H.264, H.265 и, возможно (я нормативные документы по AV1, VP8 и VP9 не читал), для других, является режим вычисления и кодирования всех коэффициентов ДКП и отсчётов сигналов как 10- или 12-разрядных чисел. В этой процедуре имеется смысл даже если и исходный материал (например, сканы киноленты или не подвергавшиеся сжатию с потерями изображения с цифровых камер) имеет 8-разрядные отсчёты, и устройство отображения имеет возможность воспроизведения лишь с 8-разрядными отсчётами. И тому есть два аргумента:
- вычисления выполняются с большей точностью, а погрешность округления обеспечивает сигнал искажений только при выводе;
- хранение в потоке данных чисел большей точности снижает эффективность сжатия, но современные кодеры имеют достаточно богатые возможности к решению многокритериальной оптимизационной задачи и найти более устойчивое решение в противоречии между шириной потока и точностью воспроизведения.
Впрочем, я весьма скептически отношусь «пережиманию пережаток» — если исходная последовательность была уже серьёзно искажена при кодировании с потерями, то ошибочно, я считаю, ожидать, что слепое применение 10-битного режима кодирования позволит «ещё немного» повысить эффективность сжатия относительно «весьма незначительного» увеличения искажений.
В его случае происходить, скорее всего, не должно такого преобразования, т. к. исходная уже в YUV.
О преобразованиях цветовых пространств можно прочесть здесь https://trac.ffmpeg.org/wiki/colorspace
По исходнику libswscale есть пара мест для функций, осуществляющих преобразования между цветовыми пространствами:
https://ffmpeg.org/doxygen/trunk/rgb2rgb__template_8c_source.html#l00649
https://ffmpeg.org/doxygen/trunk/yuv2rgb_8c_source.html#l00048
https://ffmpeg.org/doxygen/trunk/swscale_8c_source.html#l00747
Там внутренние вычисления векторов YUV и RGB ведутся в 32-разрядных типах — int или int32_t. Либо коэффициенты преобразования определены в int32_t, либо к типу int приводится произведение целочисленного отсчёта на коэффициент, определённых десятичной дробью.
Не в плавающих, а в дробных. И не обязательно с плавающей точкой. Есть варианты в дробных числах с фиксированным разделителем.
Преобразования между пространством RGB и цветоразностными пространствами будут во всех стандартных случаях дробными. Такое положение дел определяется условием нормирования у матриц преобразований:
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020
https://color.org/chardata/rgb/BT601.xalter
https://color.org/chardata/rgb/BT709.xalter
https://color.org/chardata/rgb/BT2020.xalter
>>3205319 →
В первой строчке это требование декодировать обязательно в цветовое пространство YUV (колориметрические параметры не уточняется, тем не менее, лол) с прореживанием 4:2:0 и разрядностью числовых значений компонент по 10 бит. В большинстве случаев это анимешничьи выебоны.
>Не работает ссылка.
Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.
>То это это про битность кодирования отдельных гармоник после косинусного преобразования?
Не гармоник, а коэффициентов преобразования.
Давным давно в далёкой-далёкой галактике был MPEG-2, у которого в профиле Main на уровне Main была опция, позволяющая представлять с большей точностью (10 бит) только коэффициент постоянной составляющей для блока 8×8. Входные и выходные данные при этом представлялись 8-разрядным числом (целым или дробным с фиксированным разделителем, что суть одно и то же). На глаз это должно было повышать качество воспроизводимой последовательности. Рассуждения примерно такие:
- коэффициент постоянной составляющей является результатом вычислений и при его округлении в процессе нормирования при ДКП имеется искажение, дисперсия которого с точностью до постоянного множителя является энергией или мощностью сигнала искажения; так если цена младшего значащего разряда меньше на два двоичных порядка (в 4 раза), то дисперсия, энергия и мощность сигнала искажения уменьшаются в 16 раз;
- уменьшение мощности искажений при вычислении прямого ДКП, обратного ДКП и квантовании коэффициентов ДКП позволит получить более точное восстановление постоянных составляющие в блоках воспроизводимого сигнала, что сделает менее заметной на глаз разность в яркости смежных блоков на тех участках изображение, где эта разность не замаскирована высокочастотными составляющими (например, градиенты большой площади, изображения неба с малым количеством облаков и т. д.);
- в процессе подбора параметра квантования у кодера появляется возможность более точно решить оптимизационную задачу уже при двухкритериальной целевой функции — СКО-подобный (энергетический) показатель искажений восстановленного сигнала и количество информации для представления требуемых элементов в закодированном потоке.
Более обобщим способом для современных кодеров по H.264, H.265 и, возможно (я нормативные документы по AV1, VP8 и VP9 не читал), для других, является режим вычисления и кодирования всех коэффициентов ДКП и отсчётов сигналов как 10- или 12-разрядных чисел. В этой процедуре имеется смысл даже если и исходный материал (например, сканы киноленты или не подвергавшиеся сжатию с потерями изображения с цифровых камер) имеет 8-разрядные отсчёты, и устройство отображения имеет возможность воспроизведения лишь с 8-разрядными отсчётами. И тому есть два аргумента:
- вычисления выполняются с большей точностью, а погрешность округления обеспечивает сигнал искажений только при выводе;
- хранение в потоке данных чисел большей точности снижает эффективность сжатия, но современные кодеры имеют достаточно богатые возможности к решению многокритериальной оптимизационной задачи и найти более устойчивое решение в противоречии между шириной потока и точностью воспроизведения.
Впрочем, я весьма скептически отношусь «пережиманию пережаток» — если исходная последовательность была уже серьёзно искажена при кодировании с потерями, то ошибочно, я считаю, ожидать, что слепое применение 10-битного режима кодирования позволит «ещё немного» повысить эффективность сжатия относительно «весьма незначительного» увеличения искажений.
>Или про битность RGB->YUV преобразования?
В его случае происходить, скорее всего, не должно такого преобразования, т. к. исходная уже в YUV.
О преобразованиях цветовых пространств можно прочесть здесь https://trac.ffmpeg.org/wiki/colorspace
По исходнику libswscale есть пара мест для функций, осуществляющих преобразования между цветовыми пространствами:
https://ffmpeg.org/doxygen/trunk/rgb2rgb__template_8c_source.html#l00649
https://ffmpeg.org/doxygen/trunk/yuv2rgb_8c_source.html#l00048
https://ffmpeg.org/doxygen/trunk/swscale_8c_source.html#l00747
Там внутренние вычисления векторов YUV и RGB ведутся в 32-разрядных типах — int или int32_t. Либо коэффициенты преобразования определены в int32_t, либо к типу int приводится произведение целочисленного отсчёта на коэффициент, определённых десятичной дробью.
>Да по идее оно и так в плавающих числах должно производится, чтобы избежать проблем.
Не в плавающих, а в дробных. И не обязательно с плавающей точкой. Есть варианты в дробных числах с фиксированным разделителем.
Преобразования между пространством RGB и цветоразностными пространствами будут во всех стандартных случаях дробными. Такое положение дел определяется условием нормирования у матриц преобразований:
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020
https://color.org/chardata/rgb/BT601.xalter
https://color.org/chardata/rgb/BT709.xalter
https://color.org/chardata/rgb/BT2020.xalter
>>3205319 →
>-pix_fmt yuv420p10le
>Что это?
В первой строчке это требование декодировать обязательно в цветовое пространство YUV (колориметрические параметры не уточняется, тем не менее, лол) с прореживанием 4:2:0 и разрядностью числовых значений компонент по 10 бит. В большинстве случаев это анимешничьи выебоны.
>>3205329 →
Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.
Не гармоник, а коэффициентов преобразования.
Давным давно в далёкой-далёкой галактике был MPEG-2, у которого в профиле Main на уровне Main была опция, позволяющая представлять с большей точностью (10 бит) только коэффициент постоянной составляющей для блока 8×8. Входные и выходные данные при этом представлялись 8-разрядным числом (целым или дробным с фиксированным разделителем, что суть одно и то же). На глаз это должно было повышать качество воспроизводимой последовательности. Рассуждения примерно такие:
- коэффициент постоянной составляющей является результатом вычислений и при его округлении в процессе нормирования при ДКП имеется искажение, дисперсия которого с точностью до постоянного множителя является энергией или мощностью сигнала искажения; так если цена младшего значащего разряда меньше на два двоичных порядка (в 4 раза), то дисперсия, энергия и мощность сигнала искажения уменьшаются в 16 раз;
- уменьшение мощности искажений при вычислении прямого ДКП, обратного ДКП и квантовании коэффициентов ДКП позволит получить более точное восстановление постоянных составляющие в блоках воспроизводимого сигнала, что сделает менее заметной на глаз разность в яркости смежных блоков на тех участках изображение, где эта разность не замаскирована высокочастотными составляющими (например, градиенты большой площади, изображения неба с малым количеством облаков и т. д.);
- в процессе подбора параметра квантования у кодера появляется возможность более точно решить оптимизационную задачу уже при двухкритериальной целевой функции — СКО-подобный (энергетический) показатель искажений восстановленного сигнала и количество информации для представления требуемых элементов в закодированном потоке.
Более обобщим способом для современных кодеров по H.264, H.265 и, возможно (я нормативные документы по AV1, VP8 и VP9 не читал), для других, является режим вычисления и кодирования всех коэффициентов ДКП и отсчётов сигналов как 10- или 12-разрядных чисел. В этой процедуре имеется смысл даже если и исходный материал (например, сканы киноленты или не подвергавшиеся сжатию с потерями изображения с цифровых камер) имеет 8-разрядные отсчёты, и устройство отображения имеет возможность воспроизведения лишь с 8-разрядными отсчётами. И тому есть два аргумента:
- вычисления выполняются с большей точностью, а погрешность округления обеспечивает сигнал искажений только при выводе;
- хранение в потоке данных чисел большей точности снижает эффективность сжатия, но современные кодеры имеют достаточно богатые возможности к решению многокритериальной оптимизационной задачи и найти более устойчивое решение в противоречии между шириной потока и точностью воспроизведения.
Впрочем, я весьма скептически отношусь «пережиманию пережаток» — если исходная последовательность была уже серьёзно искажена при кодировании с потерями, то ошибочно, я считаю, ожидать, что слепое применение 10-битного режима кодирования позволит «ещё немного» повысить эффективность сжатия относительно «весьма незначительного» увеличения искажений.
В его случае происходить, скорее всего, не должно такого преобразования, т. к. исходная уже в YUV.
О преобразованиях цветовых пространств можно прочесть здесь https://trac.ffmpeg.org/wiki/colorspace
По исходнику libswscale есть пара мест для функций, осуществляющих преобразования между цветовыми пространствами:
https://ffmpeg.org/doxygen/trunk/rgb2rgb__template_8c_source.html#l00649
https://ffmpeg.org/doxygen/trunk/yuv2rgb_8c_source.html#l00048
https://ffmpeg.org/doxygen/trunk/swscale_8c_source.html#l00747
Там внутренние вычисления векторов YUV и RGB ведутся в 32-разрядных типах — int или int32_t. Либо коэффициенты преобразования определены в int32_t, либо к типу int приводится произведение целочисленного отсчёта на коэффициент, определённых десятичной дробью.
Не в плавающих, а в дробных. И не обязательно с плавающей точкой. Есть варианты в дробных числах с фиксированным разделителем.
Преобразования между пространством RGB и цветоразностными пространствами будут во всех стандартных случаях дробными. Такое положение дел определяется условием нормирования у матриц преобразований:
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020
https://color.org/chardata/rgb/BT601.xalter
https://color.org/chardata/rgb/BT709.xalter
https://color.org/chardata/rgb/BT2020.xalter
>>3205319 →
В первой строчке это требование декодировать обязательно в цветовое пространство YUV (колориметрические параметры не уточняется, тем не менее, лол) с прореживанием 4:2:0 и разрядностью числовых значений компонент по 10 бит. В большинстве случаев это анимешничьи выебоны.
>Не работает ссылка.
Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.
>То это это про битность кодирования отдельных гармоник после косинусного преобразования?
Не гармоник, а коэффициентов преобразования.
Давным давно в далёкой-далёкой галактике был MPEG-2, у которого в профиле Main на уровне Main была опция, позволяющая представлять с большей точностью (10 бит) только коэффициент постоянной составляющей для блока 8×8. Входные и выходные данные при этом представлялись 8-разрядным числом (целым или дробным с фиксированным разделителем, что суть одно и то же). На глаз это должно было повышать качество воспроизводимой последовательности. Рассуждения примерно такие:
- коэффициент постоянной составляющей является результатом вычислений и при его округлении в процессе нормирования при ДКП имеется искажение, дисперсия которого с точностью до постоянного множителя является энергией или мощностью сигнала искажения; так если цена младшего значащего разряда меньше на два двоичных порядка (в 4 раза), то дисперсия, энергия и мощность сигнала искажения уменьшаются в 16 раз;
- уменьшение мощности искажений при вычислении прямого ДКП, обратного ДКП и квантовании коэффициентов ДКП позволит получить более точное восстановление постоянных составляющие в блоках воспроизводимого сигнала, что сделает менее заметной на глаз разность в яркости смежных блоков на тех участках изображение, где эта разность не замаскирована высокочастотными составляющими (например, градиенты большой площади, изображения неба с малым количеством облаков и т. д.);
- в процессе подбора параметра квантования у кодера появляется возможность более точно решить оптимизационную задачу уже при двухкритериальной целевой функции — СКО-подобный (энергетический) показатель искажений восстановленного сигнала и количество информации для представления требуемых элементов в закодированном потоке.
Более обобщим способом для современных кодеров по H.264, H.265 и, возможно (я нормативные документы по AV1, VP8 и VP9 не читал), для других, является режим вычисления и кодирования всех коэффициентов ДКП и отсчётов сигналов как 10- или 12-разрядных чисел. В этой процедуре имеется смысл даже если и исходный материал (например, сканы киноленты или не подвергавшиеся сжатию с потерями изображения с цифровых камер) имеет 8-разрядные отсчёты, и устройство отображения имеет возможность воспроизведения лишь с 8-разрядными отсчётами. И тому есть два аргумента:
- вычисления выполняются с большей точностью, а погрешность округления обеспечивает сигнал искажений только при выводе;
- хранение в потоке данных чисел большей точности снижает эффективность сжатия, но современные кодеры имеют достаточно богатые возможности к решению многокритериальной оптимизационной задачи и найти более устойчивое решение в противоречии между шириной потока и точностью воспроизведения.
Впрочем, я весьма скептически отношусь «пережиманию пережаток» — если исходная последовательность была уже серьёзно искажена при кодировании с потерями, то ошибочно, я считаю, ожидать, что слепое применение 10-битного режима кодирования позволит «ещё немного» повысить эффективность сжатия относительно «весьма незначительного» увеличения искажений.
>Или про битность RGB->YUV преобразования?
В его случае происходить, скорее всего, не должно такого преобразования, т. к. исходная уже в YUV.
О преобразованиях цветовых пространств можно прочесть здесь https://trac.ffmpeg.org/wiki/colorspace
По исходнику libswscale есть пара мест для функций, осуществляющих преобразования между цветовыми пространствами:
https://ffmpeg.org/doxygen/trunk/rgb2rgb__template_8c_source.html#l00649
https://ffmpeg.org/doxygen/trunk/yuv2rgb_8c_source.html#l00048
https://ffmpeg.org/doxygen/trunk/swscale_8c_source.html#l00747
Там внутренние вычисления векторов YUV и RGB ведутся в 32-разрядных типах — int или int32_t. Либо коэффициенты преобразования определены в int32_t, либо к типу int приводится произведение целочисленного отсчёта на коэффициент, определённых десятичной дробью.
>Да по идее оно и так в плавающих числах должно производится, чтобы избежать проблем.
Не в плавающих, а в дробных. И не обязательно с плавающей точкой. Есть варианты в дробных числах с фиксированным разделителем.
Преобразования между пространством RGB и цветоразностными пространствами будут во всех стандартных случаях дробными. Такое положение дел определяется условием нормирования у матриц преобразований:
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020
https://color.org/chardata/rgb/BT601.xalter
https://color.org/chardata/rgb/BT709.xalter
https://color.org/chardata/rgb/BT2020.xalter
>>3205319 →
>-pix_fmt yuv420p10le
>Что это?
В первой строчке это требование декодировать обязательно в цветовое пространство YUV (колориметрические параметры не уточняется, тем не менее, лол) с прореживанием 4:2:0 и разрядностью числовых значений компонент по 10 бит. В большинстве случаев это анимешничьи выебоны.
>>05534
Не очень понятно почему все промежуточные вычисления не делаются в 32 бита, и только конечное представление ужимается в 8-10 или другое случайное количество бит, где может быть как целое число, так и даже своя шкала, по типу что 0b0001 == 0.001, 0b0010 == 0.003, 0b0011 == 0.007 (которая супер-медленная для промежуточных рассчётов, но чуть эффективнее для сохранения) - как будет короче записать, с обычными числами или сохранив ещё и таблицу для нужного количества бит.
Просто по идее разница между 0 и 1, или 3 и 4 на глаз заметнее, чем разница между 245 и 246, если даже тупо в пеинте одну компоненту поменять, так как яркость заметнее изменяется - потому я и предложил шкалу имеющие шаги ниже ближе к нулю.
Да я просто как вариант. Процессор вроде бы одинаково быстро умножает.
Точно? То есть оно видя исходные сигналы уже в нужном представлении пережимать их сначала в rgb не будет?
Но такое не сработает, если есть хоть один фильтр что-то делающий с rgb-представлением, и тогда становится не очень понятно - почему libjxl встренные в ffmpeg не может без потерь jpg трогать, если у кодера есть доступ к сырым данным с декодера.
Понял в двух словах вроде бы, спасибо.
>- вычисления выполняются с большей точностью
Не очень понятно почему все промежуточные вычисления не делаются в 32 бита, и только конечное представление ужимается в 8-10 или другое случайное количество бит, где может быть как целое число, так и даже своя шкала, по типу что 0b0001 == 0.001, 0b0010 == 0.003, 0b0011 == 0.007 (которая супер-медленная для промежуточных рассчётов, но чуть эффективнее для сохранения) - как будет короче записать, с обычными числами или сохранив ещё и таблицу для нужного количества бит.
Просто по идее разница между 0 и 1, или 3 и 4 на глаз заметнее, чем разница между 245 и 246, если даже тупо в пеинте одну компоненту поменять, так как яркость заметнее изменяется - потому я и предложил шкалу имеющие шаги ниже ближе к нулю.
>И не обязательно с плавающей точкой.
Да я просто как вариант. Процессор вроде бы одинаково быстро умножает.
>не должно такого преобразования
Точно? То есть оно видя исходные сигналы уже в нужном представлении пережимать их сначала в rgb не будет?
Но такое не сработает, если есть хоть один фильтр что-то делающий с rgb-представлением, и тогда становится не очень понятно - почему libjxl встренные в ffmpeg не может без потерь jpg трогать, если у кодера есть доступ к сырым данным с декодера.
Понял в двух словах вроде бы, спасибо.
>>05553
Даже самые современные x86_64 работают с целыми разика в полтора быстрее. Плюс умножение и сложений целых и дробных с фиксированным разделителем происходит без потерь, а у дробных с плавающим разделителем с этим ай-ай-ай.
Потому, что прифит околонулевой, а затраты растут сразу и существенно. В качестве примера предложу тебе в столбик 31 на 42 и 7531 на 8642. Просто держи в уме, что кодер и декодер у нас могут стоять хоть в утюге и быть чисто аппаратными, и требования по минимуму потребляемой энергии отменять никто не будет. А кодер и декодер должны иметь существенную универсальную часть, и для оценки качества должны иметь точно воспроизводимый результат. За последнее при принятии, например, стандарта уже на MPEG-4 ASP H.263 бились (в H.264 уже победили, точно определив универсальный единый для всех реализаций способ вычисления ДКП).
Не могу понять, какая тут связь.
Если явно не попросишь, то не будет. Соответствующие проверки в коде libswscale есть.
Здесь тоже вопрос не понимаю.
> Процессор вроде бы одинаково быстро умножает.
Даже самые современные x86_64 работают с целыми разика в полтора быстрее. Плюс умножение и сложений целых и дробных с фиксированным разделителем происходит без потерь, а у дробных с плавающим разделителем с этим ай-ай-ай.
> Не очень понятно почему все промежуточные вычисления не делаются в 32 бита
Потому, что прифит околонулевой, а затраты растут сразу и существенно. В качестве примера предложу тебе в столбик 31 на 42 и 7531 на 8642. Просто держи в уме, что кодер и декодер у нас могут стоять хоть в утюге и быть чисто аппаратными, и требования по минимуму потребляемой энергии отменять никто не будет. А кодер и декодер должны иметь существенную универсальную часть, и для оценки качества должны иметь точно воспроизводимый результат. За последнее при принятии, например, стандарта уже на MPEG-4 ASP H.263 бились (в H.264 уже победили, точно определив универсальный единый для всех реализаций способ вычисления ДКП).
> потому я и предложил шкалу имеющие шаги ниже ближе к нулю
Не могу понять, какая тут связь.
>в нужном представлении пережимать их сначала в rgb не будет?
Если явно не попросишь, то не будет. Соответствующие проверки в коде libswscale есть.
>тогда становится не очень понятно - почему libjxl встренные в ffmpeg не может без потерь jpg трогать, если у кодера есть доступ к сырым данным с декодера
Здесь тоже вопрос не понимаю.
>>05595
Это скорее не вопрос, а мысли в слух, никто не может взять в толк почему libjxl входящий в состав ffmpeg не может пережимать jpeg без потерь, как это делает другая реализация энкодера этого формата, а занимается преобразованиями, которые приводят к искажениям. В то время как для libx264, входящий в тот же ffmpeg позволительно сразу работать с yuv
В общем не бери в голову.
> Здесь тоже вопрос не понимаю
Это скорее не вопрос, а мысли в слух, никто не может взять в толк почему libjxl входящий в состав ffmpeg не может пережимать jpeg без потерь, как это делает другая реализация энкодера этого формата, а занимается преобразованиями, которые приводят к искажениям. В то время как для libx264, входящий в тот же ffmpeg позволительно сразу работать с yuv
В общем не бери в голову.
40 Кб, 577x594>>05595
Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?
Причём там же инструкция есть для сложения-умножения для плавающих на 32 и 64, а для целых я такой не вижу.
Почему libjxl поддерживает перекодирование из jpg без потерь только вне ffmpeg?
>Даже самые современные x86_64 работают с целыми разика в полтора быстрее
Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?
Причём там же инструкция есть для сложения-умножения для плавающих на 32 и 64, а для целых я такой не вижу.
>Здесь тоже вопрос не понимаю.
Почему libjxl поддерживает перекодирование из jpg без потерь только вне ffmpeg?
>>05627
Знаешь, ты меня заинтриговал. Я погуглил. Оказалось, что моë мнение ошибочно.
https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware
Посоны утверждают, что в зависимости от длины чисел и конкретного камня получается по-разному. Если тебе есть, что сказать, то я бы с удовольствием послушал подробности. По остальным тезисам замечания есть?
>Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?
Знаешь, ты меня заинтриговал. Я погуглил. Оказалось, что моë мнение ошибочно.
https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware
Посоны утверждают, что в зависимости от длины чисел и конкретного камня получается по-разному. Если тебе есть, что сказать, то я бы с удовольствием послушал подробности. По остальным тезисам замечания есть?
>>05717
Я может слепой, но там начиная с хасвеллов инты считаются быстрее, что короткие, что длинные, если это инты, конечно.
Я может слепой, но там начиная с хасвеллов инты считаются быстрее, что короткие, что длинные, если это инты, конечно.
>>05384 (OP)
Сжатие медиа - это, конечно, хорошо. Но как на счёт сжатия документов и программ?
Отдаю предпочтение 7-zip с кодеком lzma2 на максимальных настройках. Кто-то скажет, что мейнстрим, но выбирать не из чего. Альтернативы - мутная незадокументированная чепуха, без комьюнити и без бинарников. Которая, к тому же, не может сжимать несколько файлов и папки - то есть сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь в модный архивный кодек. А иногда и выигрыша в степени сжатия нет.
Сжатие медиа - это, конечно, хорошо. Но как на счёт сжатия документов и программ?
Отдаю предпочтение 7-zip с кодеком lzma2 на максимальных настройках. Кто-то скажет, что мейнстрим, но выбирать не из чего. Альтернативы - мутная незадокументированная чепуха, без комьюнити и без бинарников. Которая, к тому же, не может сжимать несколько файлов и папки - то есть сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь в модный архивный кодек. А иногда и выигрыша в степени сжатия нет.
>>05717
Я просто тестил, и операции умножения-сложения на моём ноуте (да и не только на нём, до чего дотянулся) быстрее для float32, чем для целых чисел. Даже без simd.
Медленнее, только если упирается в скорость памяти, и условно говоря целые числа влезают в кеш, а флоаты - нет.
Не знаю, могу примерно описать что имею ввиду про неравномерную шкалу и у меня есть ещё несколько теоретических вопросов, но ничего такого важного.
>>05719
Деление вообще хуета неоптимизированная, но оно и не используется в кучи вычислительных задач. Как впрочем и тригонометрия, где тебе перемножать коэффициенты в разы быстрее, чем складывать углы и считать синус-косинус заново, и в кучи задач тригонометрию можно на что-то заменить.
>>05730
Можешь диск в оперативке сделать, и тар на нём размешать.
Всё плохо, сжимать с потерями нельзя, потому хотя бы немного неупорядочненную информацию сжать нельзя. Программы не сжимаются, документы, только если формат текстовый, в противном случае едва ли даже 20% получишь. А если там хоть одна картинка в документе, то смысл теряется.
Я просто тестил, и операции умножения-сложения на моём ноуте (да и не только на нём, до чего дотянулся) быстрее для float32, чем для целых чисел. Даже без simd.
Медленнее, только если упирается в скорость памяти, и условно говоря целые числа влезают в кеш, а флоаты - нет.
Не знаю, могу примерно описать что имею ввиду про неравномерную шкалу и у меня есть ещё несколько теоретических вопросов, но ничего такого важного.
>>05719
Деление вообще хуета неоптимизированная, но оно и не используется в кучи вычислительных задач. Как впрочем и тригонометрия, где тебе перемножать коэффициенты в разы быстрее, чем складывать углы и считать синус-косинус заново, и в кучи задач тригонометрию можно на что-то заменить.
>>05730
Можешь диск в оперативке сделать, и тар на нём размешать.
>Но как на счёт сжатия документов и программ?
Всё плохо, сжимать с потерями нельзя, потому хотя бы немного неупорядочненную информацию сжать нельзя. Программы не сжимаются, документы, только если формат текстовый, в противном случае едва ли даже 20% получишь. А если там хоть одна картинка в документе, то смысл теряется.
Всегда казалось что ffmpeg это какая-то сложная фигня, которую я никогда не осилю, а вот сегодня таки попробовал поделать вебмок, и на удивление всё оказалось легко и просто.
Кстати, в ffmpeg можно монтировать видосы как в Адоб премьере, или такая себе затея?
Кстати, в ffmpeg можно монтировать видосы как в Адоб премьере, или такая себе затея?
>>05743
Ну, она сложная, если ты, как пердолики сверху, будешь ебаться с битностью, хуитностью и прочими параметрами, которые нам, простым домозяйкам, непонятны. А на базовом уровне это обычная консольная утилита - скормил аргументы в нужном порядке и получил профит. Изи ту лёрн, хард ту мастер.
Ну, она сложная, если ты, как пердолики сверху, будешь ебаться с битностью, хуитностью и прочими параметрами, которые нам, простым домозяйкам, непонятны. А на базовом уровне это обычная консольная утилита - скормил аргументы в нужном порядке и получил профит. Изи ту лёрн, хард ту мастер.
>>05730
И упаковываешь их в tar. И теребишь им bzip2.
А что, перенаправление ввода-вывода отменили уже?
>>05718
Насколько я понимаю результаты, суть в том, что целые и дробные числа числодробят у Штеуда разные процессоры, разрабатываемые разными командами. И коммерческие камни компонуются из наиболее отработанного на момент выхода решения, плюс ограничения ввода-вывода, которые даёт память и её контроллер.
>>05731
Есть монография «Recent Advances in Multimedia Signal Processing and Communications» Растислава Лукача. Номерок в libgen — 651313.
Там есть первая же заметка «Color in Multimedia» о цвете как ощущении, цветовых моделях и пространствах.
Таблицей берут или в ряд Тейлора же.
>>05743
Так-то, да. Я её исходники читаю с большим трудом. И не потому, что они написаны плохо. Примерно соглашусь с >>05793.
>>05793
Можно, но зачем, когда она для этого, мягко говоря, не приспособлена.
Очень-очень такая себе. Если есть желание автоматизировать, то есть vapoursynth — нелинейный видеоредактор питоном (в смысле, что он построен как фреймсервер с питоновыми биндами и опускаемой обвязкой — можно сразу на упрощённом питоне писать редактирующий видео сценарий).
> сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь
И упаковываешь их в tar. И теребишь им bzip2.
А что, перенаправление ввода-вывода отменили уже?
>>05718
Насколько я понимаю результаты, суть в том, что целые и дробные числа числодробят у Штеуда разные процессоры, разрабатываемые разными командами. И коммерческие камни компонуются из наиболее отработанного на момент выхода решения, плюс ограничения ввода-вывода, которые даёт память и её контроллер.
>>05731
>Не знаю, могу примерно описать что имею ввиду про неравномерную шкалу и у меня есть ещё несколько теоретических вопросов, но ничего такого важного.
Есть монография «Recent Advances in Multimedia Signal Processing and Communications» Растислава Лукача. Номерок в libgen — 651313.
Там есть первая же заметка «Color in Multimedia» о цвете как ощущении, цветовых моделях и пространствах.
>и тригонометрия
Таблицей берут или в ряд Тейлора же.
>>05743
> ffmpeg это какая-то сложная фигня
Так-то, да. Я её исходники читаю с большим трудом. И не потому, что они написаны плохо. Примерно соглашусь с >>05793.
>>05793
>можно монтировать видосы как в Адоб премьере
Можно, но зачем, когда она для этого, мягко говоря, не приспособлена.
> или такая себе затея?
Очень-очень такая себе. Если есть желание автоматизировать, то есть vapoursynth — нелинейный видеоредактор питоном (в смысле, что он построен как фреймсервер с питоновыми биндами и опускаемой обвязкой — можно сразу на упрощённом питоне писать редактирующий видео сценарий).
>>05730
Ты ошибся тредом.
Ты ошибся тредом.
>>05836
Так и у амд разные, alu и fpu, вопрос в количестве портов, на хасвелле их стало 4, которые могут в алу(некоторые вроде вообще кроме алу и сдвига больше ничего не делают), в интернетах есть блоксхема примерного состава этих портов, в тайгерлейке портов стало 5 и расширены в очередной раз их возможности, вплоть до авх инструкций.
Но возможно изменена и логика работы этих блоков вычислений, за неё я не знаю.
>целые и дробные числа числодробят у Штеуда разные
Так и у амд разные, alu и fpu, вопрос в количестве портов, на хасвелле их стало 4, которые могут в алу(некоторые вроде вообще кроме алу и сдвига больше ничего не делают), в интернетах есть блоксхема примерного состава этих портов, в тайгерлейке портов стало 5 и расширены в очередной раз их возможности, вплоть до авх инструкций.
Но возможно изменена и логика работы этих блоков вычислений, за неё я не знаю.
>>05860
Я именно про это и говорю. Не стал использовать вводную конструкцию «в смысле», чтобы явно обозначить объект и предмет. Я не очень хорошо изъясняюсь — и прошу прощения за это.
Я именно про это и говорю. Не стал использовать вводную конструкцию «в смысле», чтобы явно обозначить объект и предмет. Я не очень хорошо изъясняюсь — и прошу прощения за это.
>>05886
Я лишь уточнил, что логику могли не менять, а скорости могли повысить за счёт увеличения количества портов обработки целочисленной арифметики, потому как прирост на хасвелле и порты там добавили. Х
Это проще, чем блок операционный переделать, хотя в каком то пне что ли целочисленнные операции вообще с ошибкой выполнялись, так что переделывают и их.
Я лишь уточнил, что логику могли не менять, а скорости могли повысить за счёт увеличения количества портов обработки целочисленной арифметики, потому как прирост на хасвелле и порты там добавили. Х
Это проще, чем блок операционный переделать, хотя в каком то пне что ли целочисленнные операции вообще с ошибкой выполнялись, так что переделывают и их.
Что лучше?
>>05926
Что за херня? У тебя два разных кадра пережатых в хламину. Как это можно сравнивать?
Что за херня? У тебя два разных кадра пережатых в хламину. Как это можно сравнивать?
>>05946
Не, это просто пик, лол. Я в треде мнения спрашиваю, допустим, у меня есть пикчи в png, что мне лучше для lossy из этих двух и что мне лучше для lossless из этих двух. Webp сразу нахуй.
Не, это просто пик, лол. Я в треде мнения спрашиваю, допустим, у меня есть пикчи в png, что мне лучше для lossy из этих двух и что мне лучше для lossless из этих двух. Webp сразу нахуй.
>>05954
Ты спрашиваешь что тебе делать с этим куском шакального пережатка пересохранённого в PNG? Удалить насовсем. Или сжать в JPEG/WEBP/HEIC/AVIF по самые помидоры, что-бы артефакты на артефактах полезли.
Ты спрашиваешь что тебе делать с этим куском шакального пережатка пересохранённого в PNG? Удалить насовсем. Или сжать в JPEG/WEBP/HEIC/AVIF по самые помидоры, что-бы артефакты на артефактах полезли.
>>05954
А если у тебя есть колекция lossless пикч которые тебе нужно пережать, то у тебя выбор из двух кодеков: AVIF и JPEG XL.
Выбирай JPEG XL если тебе нужно равномерно размазать битрейт по всей картинке.
Выбирай AVIF если тебе нужен умный кодер, который будет кодировать 5 минут твои 16 мегапикселей, но перераспределит биты так что-бы резкие детали выглядел резче, а мыльные замылились ещё больше.
А если у тебя есть колекция lossless пикч которые тебе нужно пережать, то у тебя выбор из двух кодеков: AVIF и JPEG XL.
Выбирай JPEG XL если тебе нужно равномерно размазать битрейт по всей картинке.
Выбирай AVIF если тебе нужен умный кодер, который будет кодировать 5 минут твои 16 мегапикселей, но перераспределит биты так что-бы резкие детали выглядел резче, а мыльные замылились ещё больше.
>>05994
Я думаю он всё-таки спрашивает, чем ему его коллекцию гей-порно в картниках пережать для архивации в джизипе.
Хейт в сторону лосслесс вебп вообще не вкурил.
Я думаю он всё-таки спрашивает, чем ему его коллекцию гей-порно в картниках пережать для архивации в джизипе.
Хейт в сторону лосслесс вебп вообще не вкурил.
Почему, если на двач загружаешь vp8/9, вложенное в mp4, то по ссылке оно все равно переименовывается как webm? Там не V_VP9, а vp09. С av1 тоже самое, av01 по ссылке открывается с .webm
Чё там с вебп2?
>>06616
И?
И?
Двачик, что мне делать с 10-и битным видео? Как перекодировать в 264-й, чтобы сохранить качество?
И с каких пор ффмпег перестал показывать отдельный битрейт для каждого потока, а показывает только общий?
И с каких пор ффмпег перестал показывать отдельный битрейт для каждого потока, а показывает только общий?
>>08298
Зачем это делать во-первых? Ты постить куда-то хочешь в инет или чо?
>Че? У меня релиз 265@10 бит, нужно сделоть 264@8 бит. Я спрашиваю как это сделать, вы городите чушь.
Зачем это делать во-первых? Ты постить куда-то хочешь в инет или чо?
>>08405
Так это и есть H264, но неправильный, 10-битный. Почему он сам не додумался скачать нормальный рип или ремукс, ума не приложу.
Так это и есть H264, но неправильный, 10-битный. Почему он сам не додумался скачать нормальный рип или ремукс, ума не приложу.
109 Кб, 1080x1080Почему он просто не посмотрел в интернете
>>08419
Потому что я еблан и я это признаю. На своем же скриншоте >>08229 не разглядел h264, охуеть я баран. Но от моего самобичевания лучше не станет, поэтому к теме.
Все дело в том, что я положил кучу сил на сборку конкретно этого релиза, но по какой-то странной причине не обратил внимания на битность видео, ебать релизеров в сраку. Я своими руками собирал дорожки с озвучкой и клеил их, а в итоге обнаружил, что встроенный в 11-е окна плеер не может его показать и я не сразу понял, что к чему. Да, забыл сказать для чего это все. Я никуда не выкладываю, просто хотел в коллекцию, то есть длясибя.
Короче что проще - скачать нормальный рип и заново приклеить озвучки или все же можно перекодировать видео в уже готовом контейнере?
>>08517
Храни тебя бог анон, но я вот уже сам начал сомневаться, что пережимать рип норм затея.
>не додумался
Потому что я еблан и я это признаю. На своем же скриншоте >>08229 не разглядел h264, охуеть я баран. Но от моего самобичевания лучше не станет, поэтому к теме.
Все дело в том, что я положил кучу сил на сборку конкретно этого релиза, но по какой-то странной причине не обратил внимания на битность видео, ебать релизеров в сраку. Я своими руками собирал дорожки с озвучкой и клеил их, а в итоге обнаружил, что встроенный в 11-е окна плеер не может его показать и я не сразу понял, что к чему. Да, забыл сказать для чего это все. Я никуда не выкладываю, просто хотел в коллекцию, то есть длясибя.
Короче что проще - скачать нормальный рип и заново приклеить озвучки или все же можно перекодировать видео в уже готовом контейнере?
>>08517
Храни тебя бог анон, но я вот уже сам начал сомневаться, что пережимать рип норм затея.
>>08560
Смотри, у тебя есть 2 пути, и оба ведут к торрент-трекеру.
Если для тебя установка сторонних софтовых плееров по какой-то причине неприемлима — качай рип.
Если ты хочешь сам пережать видео и ты знаешь как ты это будешь делать — качай ремукс или BluRay/DVD.
Если имеешь дело с WEB, пережатие скорее всего не требуеться, убедись только что у тебя формат видеодорожки H264 8bit а не H265 10bit HDR DolbyVision.
Смотри, у тебя есть 2 пути, и оба ведут к торрент-трекеру.
Если для тебя установка сторонних софтовых плееров по какой-то причине неприемлима — качай рип.
Если ты хочешь сам пережать видео и ты знаешь как ты это будешь делать — качай ремукс или BluRay/DVD.
Если имеешь дело с WEB, пережатие скорее всего не требуеться, убедись только что у тебя формат видеодорожки H264 8bit а не H265 10bit HDR DolbyVision.
>>08578
То есть вариант с еблей мы даже не рассматриваем, окей. Ладно, я все понял. Есть еще вопрос: зачем и нахуя люди пилят 10 бит видео? Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой. У меня пиздатый моник, не хдр конечно и не 10 бит, но у большинства людей с торрентов тоже не одиссей джи 9 или че там щас в тренде. И что сука характерно, пилят 10 бит в основном для аниме. ЗАЧЕМ?
То есть вариант с еблей мы даже не рассматриваем, окей. Ладно, я все понял. Есть еще вопрос: зачем и нахуя люди пилят 10 бит видео? Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой. У меня пиздатый моник, не хдр конечно и не 10 бит, но у большинства людей с торрентов тоже не одиссей джи 9 или че там щас в тренде. И что сука характерно, пилят 10 бит в основном для аниме. ЗАЧЕМ?
526 Кб, 740x677>>08639
Второй вариант это и есть вариант с еблей, где ты берёшь исходник лучшего какчества и уродуешь. Не рассматривается вариант пожатия пожатого.
> То есть вариант с еблей мы даже не рассматриваем
Второй вариант это и есть вариант с еблей, где ты берёшь исходник лучшего какчества и уродуешь. Не рассматривается вариант пожатия пожатого.
>>08639
Цвета лучше, сжатие лучше. Дебандинг.
Цвета лучше, сжатие лучше. Дебандинг.
8 Кб, 250x250>>08560
> скочал нормальный 10-ти битный рип
> гавна встроенная в гавну не поддерживает нормальный 10-ти битный рип
> надо угандошивать нормальный 10-ти битный рип пережатием в менее сжимаемый 8-ми битный чтобы гавна встроенная в гавну поддерживала
>>08639
Разница есть. С 8-бит в темных сценах аниме ебаные круги бандинга.
И в hi10p не тратится битрейт на борьбу с этим бандингом или чем-то другим, так что энкодер может либо сделать поменьше вес видео, либо улучшить качество с тем же весом.
Зачем - ответ выше, бандинг и сжатие. А почему - потому что могут.
Те аниме видео обычно смотрят с субтитрами. И не .srt, а .ass с оформлением. Так что требования к плеерам уже повышены. И т.к. смотрели на пк/ноутах, а не железных плеерах, то наличие аппаратного декодирования не было критичным, процы могли справиться софтверно с hd/fhd и 2-3к битрейтом. Энкодеры решили зафорсить 10бит с 2011, и это прошло относительно безболезненно, зрители обновили плееры и продолжили смотреть.
Видели шутки, которые не шутки, про то что порно индустрия много раз первой осваивала и распространяла новую технологию? Вот с аниме по сути похожая ситуация тогда произошла.
Как сейчас не знаю. Кто-то энкодит пиратство в h.265 или AV1?
> Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой.
Разница есть. С 8-бит в темных сценах аниме ебаные круги бандинга.
И в hi10p не тратится битрейт на борьбу с этим бандингом или чем-то другим, так что энкодер может либо сделать поменьше вес видео, либо улучшить качество с тем же весом.
> И что сука характерно, пилят 10 бит в основном для аниме. ЗАЧЕМ?
Зачем - ответ выше, бандинг и сжатие. А почему - потому что могут.
Те аниме видео обычно смотрят с субтитрами. И не .srt, а .ass с оформлением. Так что требования к плеерам уже повышены. И т.к. смотрели на пк/ноутах, а не железных плеерах, то наличие аппаратного декодирования не было критичным, процы могли справиться софтверно с hd/fhd и 2-3к битрейтом. Энкодеры решили зафорсить 10бит с 2011, и это прошло относительно безболезненно, зрители обновили плееры и продолжили смотреть.
Видели шутки, которые не шутки, про то что порно индустрия много раз первой осваивала и распространяла новую технологию? Вот с аниме по сути похожая ситуация тогда произошла.
Как сейчас не знаю. Кто-то энкодит пиратство в h.265 или AV1?
>>08652
Анимешники и энкодят, даже тестировали fate'вым касанием небес процессорный декод av1 в райзентреде.
> Кто-то энкодит пиратство в h.265 или AV1
Анимешники и энкодят, даже тестировали fate'вым касанием небес процессорный декод av1 в райзентреде.
>>08640
Ну зачем ты так..
>>08652
Доводы разумные и звучит все круто. Не круто, когда ты мультики не смотришь (за редким исключением) и при случае попадаешь вот в такие ситуации. Ну бывает. Большое тебе спасибо.
>>08649
Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв. Как ты узнал?
>и уродуешь
Ну зачем ты так..
>>08652
Доводы разумные и звучит все круто. Не круто, когда ты мультики не смотришь (за редким исключением) и при случае попадаешь вот в такие ситуации. Ну бывает. Большое тебе спасибо.
>>08649
Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв. Как ты узнал?
>>08666
То есть кроме стокового и MPV ничего нет? А как же MPC, тот же "потный даун", ну или VLC в конце концов? Мне казалось что этих плееров у вас там хоть жопой жуй, и выбирать можно по симпатичности GUI и нескучным обоям.
> Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв.
То есть кроме стокового и MPV ничего нет? А как же MPC, тот же "потный даун", ну или VLC в конце концов? Мне казалось что этих плееров у вас там хоть жопой жуй, и выбирать можно по симпатичности GUI и нескучным обоям.
сап сосака
Хочу перекодировать видео в вебм, но 1. чтоб видео, которые разрешением больше указанного, сжимались в габаритах, 2. чтоб они не растягивались.
К примеру, есть много файлов в 4К, и их надо довести до 720р / или же файлы 4000х4000, и их тоже надо уменьшить, допустим до 500х500.
Как делать?
Хочу перекодировать видео в вебм, но 1. чтоб видео, которые разрешением больше указанного, сжимались в габаритах, 2. чтоб они не растягивались.
К примеру, есть много файлов в 4К, и их надо довести до 720р / или же файлы 4000х4000, и их тоже надо уменьшить, допустим до 500х500.
Как делать?
>>08829
Делением как еще. Ссылку уже кинули, но почему-то через россии заблочили, пидоры. С впн открывает.
Делением как еще. Ссылку уже кинули, но почему-то через россии заблочили, пидоры. С впн открывает.
>>05384 (OP)
Моя команда для кодирование в av1 из прошлого треда. Как вам?
echo -- -- -- && time /t && echo -- -- -- && ffmpeg -i "sourcefile.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svt1av1\outfile.ivf" && ffmpeg -i "sourcefile.mkv" -map 0:a:0 -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile.opus" && ffmpeg -i "!svt1av1\outfile.ivf" -i "!svt1av1\outfile.opus" -vcodec copy -acodec copy "!svt1av1\outfile (svtav1).mkv" && echo ~~ ~~ ~~ && time /t && echo ~~ ~~ ~~
Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
--keyint 1s - очень люблю перемотку на 1-2 секунды и очень не люблю точный (медленный) поиск. Увеличивает размер файла, но не сильно.
--preset 5 - на шестом пресете жопа по качеству, на четвёртом состариться успеешь.
--crf 19 - жирно, но иначе качество ощутимо портится, 19 в самый раз. Компенсация пятого пресета.
--tune 0 - VQ (visual quality) режим, выглядит многократно лучше дефолтного PSNR (объективные математические показатели). Ума не приложу, почему не стоит по дефолту. На реддите писали о повышенной резкости, я такого не заметил.
--film-grain 8 - многие фильмы и аниме имеют шум (зерно, grain), эта опция им нужна.
yuv420p10le выбрал по гайду из шапки. Пишут, будет лучше сжатие и лучше качество.
-strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
opus выбрал за лучшую спектрограмму относительно aac >>3202282 →. Так же для опуса я нашёл значительно больше статей и тестов прослушивания, с ним не нужно заморачиваться, выбирая кодировщик и собирая ffmpeg подсибя с поддержкой fdk-aac, свободная лицензия. На хабре автор статьи писал, что порогом прозрачности у опуса для него оказался битрейт около 170, я выбрал 172 с запасом. -filter:a использую по привычке - помню, некоторое время назад, кодировал без этого ресемплера, и громкость в опусе сильно снизилась.
echo и time нужны для удобства - знать, когда я начал и закончил кодировать.
Такая команда сжимает 25-минутные аниме до 380-620 Мб (5117 Мб на 10 видео) за 120-130 минут на моём железе. В другом тайтле одна серия весит уже 500-1000 Мб, но это, полагаю, из-за более сильного шума, который к тому же двигается. Избыточная информация как-никак. Но повышение --film-grain до 16 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
Моя команда для кодирование в av1 из прошлого треда. Как вам?
echo -- -- -- && time /t && echo -- -- -- && ffmpeg -i "sourcefile.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svt1av1\outfile.ivf" && ffmpeg -i "sourcefile.mkv" -map 0:a:0 -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile.opus" && ffmpeg -i "!svt1av1\outfile.ivf" -i "!svt1av1\outfile.opus" -vcodec copy -acodec copy "!svt1av1\outfile (svtav1).mkv" && echo ~~ ~~ ~~ && time /t && echo ~~ ~~ ~~
Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
--keyint 1s - очень люблю перемотку на 1-2 секунды и очень не люблю точный (медленный) поиск. Увеличивает размер файла, но не сильно.
--preset 5 - на шестом пресете жопа по качеству, на четвёртом состариться успеешь.
--crf 19 - жирно, но иначе качество ощутимо портится, 19 в самый раз. Компенсация пятого пресета.
--tune 0 - VQ (visual quality) режим, выглядит многократно лучше дефолтного PSNR (объективные математические показатели). Ума не приложу, почему не стоит по дефолту. На реддите писали о повышенной резкости, я такого не заметил.
--film-grain 8 - многие фильмы и аниме имеют шум (зерно, grain), эта опция им нужна.
yuv420p10le выбрал по гайду из шапки. Пишут, будет лучше сжатие и лучше качество.
-strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
opus выбрал за лучшую спектрограмму относительно aac >>3202282 →. Так же для опуса я нашёл значительно больше статей и тестов прослушивания, с ним не нужно заморачиваться, выбирая кодировщик и собирая ffmpeg подсибя с поддержкой fdk-aac, свободная лицензия. На хабре автор статьи писал, что порогом прозрачности у опуса для него оказался битрейт около 170, я выбрал 172 с запасом. -filter:a использую по привычке - помню, некоторое время назад, кодировал без этого ресемплера, и громкость в опусе сильно снизилась.
echo и time нужны для удобства - знать, когда я начал и закончил кодировать.
Такая команда сжимает 25-минутные аниме до 380-620 Мб (5117 Мб на 10 видео) за 120-130 минут на моём железе. В другом тайтле одна серия весит уже 500-1000 Мб, но это, полагаю, из-за более сильного шума, который к тому же двигается. Избыточная информация как-никак. Но повышение --film-grain до 16 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
>>05384 (OP)
Моя команда для кодирование в av1 из прошлого треда. Как вам?
echo -- -- -- && time /t && echo -- -- -- && ffmpeg -i "sourcefile.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svt1av1\outfile.ivf" && ffmpeg -i "sourcefile.mkv" -map 0:a:0 -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile.opus" && ffmpeg -i "!svt1av1\outfile.ivf" -i "!svt1av1\outfile.opus" -vcodec copy -acodec copy "!svt1av1\outfile (svtav1).mkv" && echo ~~ ~~ ~~ && time /t && echo ~~ ~~ ~~
Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
--keyint 1s - очень люблю перемотку на 1-2 секунды и очень не люблю точный (медленный) поиск. Увеличивает размер файла, но не сильно.
--preset 5 - на шестом пресете жопа по качеству, на четвёртом состариться успеешь.
--crf 19 - жирно, но иначе качество ощутимо портится, 19 в самый раз. Компенсация пятого пресета.
--tune 0 - VQ (visual quality) режим, выглядит многократно лучше дефолтного PSNR (объективные математические показатели). Ума не приложу, почему не стоит по дефолту. На реддите писали о повышенной резкости, я такого не заметил.
--film-grain 8 - многие фильмы и аниме имеют шум (зерно, grain), эта опция им нужна.
yuv420p10le выбрал по гайду из шапки. Пишут, будет лучше сжатие и лучше качество.
-strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
opus выбрал за лучшую спектрограмму относительно aac >>3202282 →. Так же для опуса я нашёл значительно больше статей и тестов прослушивания, с ним не нужно заморачиваться, выбирая кодировщик и собирая ffmpeg подсибя с поддержкой fdk-aac, свободная лицензия. На хабре автор статьи писал, что порогом прозрачности у опуса для него оказался битрейт около 170, я выбрал 172 с запасом. -filter:a использую по привычке - помню, некоторое время назад, кодировал без этого ресемплера, и громкость в опусе сильно снизилась.
echo и time нужны для удобства - знать, когда я начал и закончил кодировать.
Такая команда сжимает 25-минутные аниме до 380-620 Мб (5117 Мб на 10 видео) за 120-130 минут на моём железе. В другом тайтле одна серия весит уже 500-1000 Мб, но это, полагаю, из-за более сильного шума, который к тому же двигается. Избыточная информация как-никак. Но повышение --film-grain до 16 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
Моя команда для кодирование в av1 из прошлого треда. Как вам?
echo -- -- -- && time /t && echo -- -- -- && ffmpeg -i "sourcefile.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svt1av1\outfile.ivf" && ffmpeg -i "sourcefile.mkv" -map 0:a:0 -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile.opus" && ffmpeg -i "!svt1av1\outfile.ivf" -i "!svt1av1\outfile.opus" -vcodec copy -acodec copy "!svt1av1\outfile (svtav1).mkv" && echo ~~ ~~ ~~ && time /t && echo ~~ ~~ ~~
Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
--keyint 1s - очень люблю перемотку на 1-2 секунды и очень не люблю точный (медленный) поиск. Увеличивает размер файла, но не сильно.
--preset 5 - на шестом пресете жопа по качеству, на четвёртом состариться успеешь.
--crf 19 - жирно, но иначе качество ощутимо портится, 19 в самый раз. Компенсация пятого пресета.
--tune 0 - VQ (visual quality) режим, выглядит многократно лучше дефолтного PSNR (объективные математические показатели). Ума не приложу, почему не стоит по дефолту. На реддите писали о повышенной резкости, я такого не заметил.
--film-grain 8 - многие фильмы и аниме имеют шум (зерно, grain), эта опция им нужна.
yuv420p10le выбрал по гайду из шапки. Пишут, будет лучше сжатие и лучше качество.
-strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
opus выбрал за лучшую спектрограмму относительно aac >>3202282 →. Так же для опуса я нашёл значительно больше статей и тестов прослушивания, с ним не нужно заморачиваться, выбирая кодировщик и собирая ffmpeg подсибя с поддержкой fdk-aac, свободная лицензия. На хабре автор статьи писал, что порогом прозрачности у опуса для него оказался битрейт около 170, я выбрал 172 с запасом. -filter:a использую по привычке - помню, некоторое время назад, кодировал без этого ресемплера, и громкость в опусе сильно снизилась.
echo и time нужны для удобства - знать, когда я начал и закончил кодировать.
Такая команда сжимает 25-минутные аниме до 380-620 Мб (5117 Мб на 10 видео) за 120-130 минут на моём железе. В другом тайтле одна серия весит уже 500-1000 Мб, но это, полагаю, из-за более сильного шума, который к тому же двигается. Избыточная информация как-никак. Но повышение --film-grain до 16 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
>>08856
говно/10
> дополнительный аудиодорожки проебываются
> встроенные сабы проебываются
> метаинфо проебывается
> ненужно1кодек
говно/10
>>08856
Нихуя подобного
Не нужно давно, это для ффмпег раньше только
> Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
Нихуя подобного
> -strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
Не нужно давно, это для ффмпег раньше только
>>08851
Открывает у меня.
Открывает у меня.
>>08856
В чем проблема выставить не в секундах?
Вообще-то он прав. Выставить в секундах можно в av1enc. В ffmpeg ставить только по старому, значением.
>Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
В чем проблема выставить не в секундах?
>Нихуя подобного
Вообще-то он прав. Выставить в секундах можно в av1enc. В ffmpeg ставить только по старому, значением.
>>08891
Озвучки мне не нужны, но они обычно отдельным файлом лежат. Комментарии от создателей на японском мне тоже не нужны. Остаются дорожки в 5.1 или стерео варианте, какая лучше звучит - ту и выбираю. Всё это время выбирал стерео (в тех релизах другой не было).
Делаю их внешними дополнительной командой. Внешние лучше по факту.
Какие метаданные могут быть в видеофайлах? Прогнал сейчас через ffprobe - ничего кроме encoder, creation time и очевидных заголовков ("rus subs", "flac") не нашёл. Могу добавить ещё одну команду, чтоб записывать метаданные в .txt и потом импортировать.
Сжимает лучше x265, разве нет?
>>08894
В документации к svt-av1 сказано, что --keyint в секундах только в их официальной программе https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md
Вообще, отдельный энкодер лучше комбайна, как минимум в теории.
>>09059
Не знаю. Когда читал, забыл видимо, что в секунде всегда одинаковое количество кадров.
>> дополнительный аудиодорожки проебываются
Озвучки мне не нужны, но они обычно отдельным файлом лежат. Комментарии от создателей на японском мне тоже не нужны. Остаются дорожки в 5.1 или стерео варианте, какая лучше звучит - ту и выбираю. Всё это время выбирал стерео (в тех релизах другой не было).
>> встроенные сабы проебываются
Делаю их внешними дополнительной командой. Внешние лучше по факту.
>> метаинфо проебывается
Какие метаданные могут быть в видеофайлах? Прогнал сейчас через ffprobe - ничего кроме encoder, creation time и очевидных заголовков ("rus subs", "flac") не нашёл. Могу добавить ещё одну команду, чтоб записывать метаданные в .txt и потом импортировать.
> ненужно1кодек
Сжимает лучше x265, разве нет?
>>08894
>Нихуя подобного
В документации к svt-av1 сказано, что --keyint в секундах только в их официальной программе https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md
>GOP size (frames), use s suffix for seconds (SvtAv1EncApp only) [-2: ~5 seconds, -1: "infinite" only for CRF, 0: == -1]
Вообще, отдельный энкодер лучше комбайна, как минимум в теории.
>>09059
>В чем проблема выставить не в секундах?
Не знаю. Когда читал, забыл видимо, что в секунде всегда одинаковое количество кадров.
>>09074
Нет? позиционировался и продолжает как улучшение x264. Да, лучше чем x264. x265 - нет, в лучшем случае на уровне. И уж точно в разы медленней и ресурсоемче.
Чего тогда рейт реквестируешь если сугубо для твоих хотелок и задач однострочник?
> Сжимает лучше x265, разве нет?
Нет? позиционировался и продолжает как улучшение x264. Да, лучше чем x264. x265 - нет, в лучшем случае на уровне. И уж точно в разы медленней и ресурсоемче.
>
Чего тогда рейт реквестируешь если сугубо для твоих хотелок и задач однострочник?
>>09074
По сути не лучше, потому что в ffmpeg есть встроенные плюшки по типу фильтров, скэйлингов и прочего. А параметры самого энкодера легко вписываются в -svtav1-params.
>Вообще, отдельный энкодер лучше комбайна, как минимум в теории.
По сути не лучше, потому что в ffmpeg есть встроенные плюшки по типу фильтров, скэйлингов и прочего. А параметры самого энкодера легко вписываются в -svtav1-params.
>>09088
Ты имел в виду VP9?
Ну так-то он чуть лучше HEVC, но ты попробуй заведи HEVC в хроме или фуррифоксе.
> Нет? позиционировался и продолжает как улучшение x264.
Ты имел в виду VP9?
Ну так-то он чуть лучше HEVC, но ты попробуй заведи HEVC в хроме или фуррифоксе.
>>09074
Ичо что там сказано, есть параметр --svt-params keyint:10s вроде в прошлый раз работало. Пайпинг это полнейшая хуйня всегда
Ичо что там сказано, есть параметр --svt-params keyint:10s вроде в прошлый раз работало. Пайпинг это полнейшая хуйня всегда
>>09104
Ну в смысле не VP9 а AV1.
А VP9 да, это конкурент H264, с вразы более медленным временем кодирования чем x264, ненужный нигде кроме кодирования на low-end битрейтах.
Ну в смысле не VP9 а AV1.
А VP9 да, это конкурент H264, с вразы более медленным временем кодирования чем x264, ненужный нигде кроме кодирования на low-end битрейтах.
>>09104
По факту же, если скорость кодирования не учитывать.
Даже дефолтный средний vp9 самый тяжелый hevc вроде как обгоняет...
По факту же, если скорость кодирования не учитывать.
Даже дефолтный средний vp9 самый тяжелый hevc вроде как обгоняет...
>>09120
Сравнивать надо не --cpu-used 6 с --preset placebo, а качество изображения, полученное за одинаковое время кадра.
Сравнивать надо не --cpu-used 6 с --preset placebo, а качество изображения, полученное за одинаковое время кадра.
>>09102
Почему? Неудобно может быть, согласен - команды длинные. И если команду нужно встроить куда-то, то вообще не вариант.
>Пайпинг это полнейшая хуйня всегда
Почему? Неудобно может быть, согласен - команды длинные. И если команду нужно встроить куда-то, то вообще не вариант.
>>09124
Тогда победит h264 и svt, если время малое, и что-то потяжелея, если время больше.
> полученное за одинаковое время
Тогда победит h264 и svt, если время малое, и что-то потяжелея, если время больше.
>>09126
Медленно, требует копирования огромного количества данных из одного процесса в другой, сжирает кучу оперативки, при ошибке ложатся оба процесса
Медленно, требует копирования огромного количества данных из одного процесса в другой, сжирает кучу оперативки, при ошибке ложатся оба процесса
Кодировал один и тот же исходник хорошего качества в svt-av1, а затем в x265. Окончания x265 так и не дождался, завершил на 61 секунде из 1401 всего видео.
Команда для x265:
ffmpeg -i EP01.mkv -map 0:v:0 -c:v libx265 -crf 19 -preset slower -tune grain -pix_fmt yuv420p10le -bf 16 "av1-vs-x265\EP01-x265.mkv"
Команда для svt-av1:
ffmpeg -i "EP01.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svtav1\EP01.ivf"
Кодировал вместе со звуком, но для чистоты эксперимента извлёк из mkv отдельно видео-дорожку:
x265 длительностью 61 секунда весит 157 812 Кб
av1 длительностью 1401 секунда весит 768 933 Кб
То есть разница в 4.713 раза в пользу av1
x265 кодировал 61 секунду за 24 минуты. svt-av1 кодировал 1401 секунду за 130-140 минут.
Качество одинаковое, но в x265 намного больше шума (зерна), примерно столько же, сколько и в исходнике. svt-av1 аккуратно почистил шум.
Вердикт: svt-av1 лучше по качеству, сжимает быстрее и сильнее, чем x265.
Команда для x265:
ffmpeg -i EP01.mkv -map 0:v:0 -c:v libx265 -crf 19 -preset slower -tune grain -pix_fmt yuv420p10le -bf 16 "av1-vs-x265\EP01-x265.mkv"
Команда для svt-av1:
ffmpeg -i "EP01.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svtav1\EP01.ivf"
Кодировал вместе со звуком, но для чистоты эксперимента извлёк из mkv отдельно видео-дорожку:
x265 длительностью 61 секунда весит 157 812 Кб
av1 длительностью 1401 секунда весит 768 933 Кб
То есть разница в 4.713 раза в пользу av1
x265 кодировал 61 секунду за 24 минуты. svt-av1 кодировал 1401 секунду за 130-140 минут.
Качество одинаковое, но в x265 намного больше шума (зерна), примерно столько же, сколько и в исходнике. svt-av1 аккуратно почистил шум.
Вердикт: svt-av1 лучше по качеству, сжимает быстрее и сильнее, чем x265.
>>09239
Хмм, беру свои слова назад. Неплохо поработали над ним в последних версиях ffmpeg'а.
Хмм, беру свои слова назад. Неплохо поработали над ним в последних версиях ffmpeg'а.
>>09238
Согласен, коллега. Провёл эксперимент заново, закодировал два равных по длине отрезка (-ss 70 -t 45), вот что вышло:
ffmpeg -i "EP01.mkv" -map 0:v:0 -ss 70 -t 45 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svtav1\EP01.ivf"
ffmpeg -i EP01.mkv -map 0:v:0 -ss 70 -t 45 -c:v libx265 -crf 19 -preset slower -tune grain -pix_fmt yuv420p10le -bf 16 -x265-params "keyint=24" "av1-vs-x265\EP01-x265-keyint.mkv"
>>09239
>>09246
Квадратов и мыла нет. Если не считать мылом области без сложных текстур, где в оригинале было много шума, а av1 его убрал и дофантазировал на месте шума какое-то мыльцо.
Но потери деталей имеются - на моих скриншотах видно, как в оригинале на лбу красного мехи четыре точки, и от точек в центр уходят слабо прорисованные полосы. av1 почти полностью убрал их. Но в других кадрах рядом они видны. Анимепроблемы, наверное. Но x265 сохранил эти полосы
Что же по времени и весу:
x265 - 16 минут, 127 129 Кб
av1 - 5 минут, 31 350 Кб
Заметил ещё одну очень странную вещь - если указать x265 "keyint=24", то вес файла уменьшится. Без этой опции 131 868 Кб, и ключевые кадры расставлены раз в 12 секунд по моим наблюдениям. Хотя должно быть ровно наоборот - больше ключевых кадров = больше вес файла.
Согласен, коллега. Провёл эксперимент заново, закодировал два равных по длине отрезка (-ss 70 -t 45), вот что вышло:
ffmpeg -i "EP01.mkv" -map 0:v:0 -ss 70 -t 45 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svtav1\EP01.ivf"
ffmpeg -i EP01.mkv -map 0:v:0 -ss 70 -t 45 -c:v libx265 -crf 19 -preset slower -tune grain -pix_fmt yuv420p10le -bf 16 -x265-params "keyint=24" "av1-vs-x265\EP01-x265-keyint.mkv"
>>09239
>>09246
Квадратов и мыла нет. Если не считать мылом области без сложных текстур, где в оригинале было много шума, а av1 его убрал и дофантазировал на месте шума какое-то мыльцо.
Но потери деталей имеются - на моих скриншотах видно, как в оригинале на лбу красного мехи четыре точки, и от точек в центр уходят слабо прорисованные полосы. av1 почти полностью убрал их. Но в других кадрах рядом они видны. Анимепроблемы, наверное. Но x265 сохранил эти полосы
Что же по времени и весу:
x265 - 16 минут, 127 129 Кб
av1 - 5 минут, 31 350 Кб
Заметил ещё одну очень странную вещь - если указать x265 "keyint=24", то вес файла уменьшится. Без этой опции 131 868 Кб, и ключевые кадры расставлены раз в 12 секунд по моим наблюдениям. Хотя должно быть ровно наоборот - больше ключевых кадров = больше вес файла.
10,2 Мб, 3840x2160>>09257
И скриншот оригинала, который я не успел добавить к первому сообщению, потому-что капча обновлялась быстрее, чем я загружал.
И скриншот оригинала, который я не успел добавить к первому сообщению, потому-что капча обновлялась быстрее, чем я загружал.
>>09261
av1 сжимает в несколько раз эффективнее, ещё и шум убирает, так что x265 не надо использовать вообще.
av1 сжимает в несколько раз эффективнее, ещё и шум убирает, так что x265 не надо использовать вообще.
>>09269
ты ведь пыняешь, что crf 19 в x265 и av1 не одно и тоже. Кодировать надо с одинаковым битрейтом.
ты ведь пыняешь, что crf 19 в x265 и av1 не одно и тоже. Кодировать надо с одинаковым битрейтом.
>>09270
Да, посмотрел на другую часть картинки и заметил.
Как же тогда сжимать видео, чтобы без потери деталей?
Да, посмотрел на другую часть картинки и заметил.
Как же тогда сжимать видео, чтобы без потери деталей?
>>09344
Зачем тогда этот тред нужен, если здесь предлагают "оставить как есть" и "раздуть до 10 мбит/с"?
Зачем тогда этот тред нужен, если здесь предлагают "оставить как есть" и "раздуть до 10 мбит/с"?
19,8 Мб, webm,320x180, 127:23
>>09345
Это залётыши. Тру юзеры ффмпега смотрят фильмы только так.
Это залётыши. Тру юзеры ффмпега смотрят фильмы только так.
>>09347
Шакал Квадратович, добро пожаловать!
Шакал Квадратович, добро пожаловать!
>>09347
А может кто-то загрузить и через svt такое сделать на 20 мб, для теста?
У меня просто мобилка, 200 кбит/с.
А может кто-то загрузить и через svt такое сделать на 20 мб, для теста?
У меня просто мобилка, 200 кбит/с.
Есть ли толк перегонять AVC в HEVC ради уменьшения размера (с допустимой незначительной потерей качества)? Или это беспонтовая затея уровня "конвертировать из lossy MP3 в другой lossy-формат"?
>>09416
Вероятно. По идее от битрейта зависит, а битрейт динамически выставляется crf - чем загруженнее сцена, тем больше на неё битрейт.
Надеюсь, что всё-таки проблема тех скриншотов из-за чрезмерного шума, и в современных тайтлах, где шума нет, или незначительно мало, svtav1 будет кодировать намного лучше. За сегодняшний день я изрядно огорчился в способностях кодеков, думал, сожму раз эдак в 6 без видимых глазу потерь, но нет. Хотя с предыдущим тайтлом получилось сжать без видимых потерь, или может я слишком мало сцен там сравнивал.
>изрядная дрисня вероятно будет получаться
Вероятно. По идее от битрейта зависит, а битрейт динамически выставляется crf - чем загруженнее сцена, тем больше на неё битрейт.
Надеюсь, что всё-таки проблема тех скриншотов из-за чрезмерного шума, и в современных тайтлах, где шума нет, или незначительно мало, svtav1 будет кодировать намного лучше. За сегодняшний день я изрядно огорчился в способностях кодеков, думал, сожму раз эдак в 6 без видимых глазу потерь, но нет. Хотя с предыдущим тайтлом получилось сжать без видимых потерь, или может я слишком мало сцен там сравнивал.
>>05384 (OP)
О каком "баттле" может идти речь, если VVC не поддерживается в mpv, только в васянской сборке https://github.com/MartinEesmaa/VVCEasy ? В других плеерах тоже не поддерживается, только через мокрописи-дополнения. И в ffmpeg его нет. Хуйня сырая в общем, ждём.
> ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
О каком "баттле" может идти речь, если VVC не поддерживается в mpv, только в васянской сборке https://github.com/MartinEesmaa/VVCEasy ? В других плеерах тоже не поддерживается, только через мокрописи-дополнения. И в ffmpeg его нет. Хуйня сырая в общем, ждём.
>>09405
Именно.
>>09345
Какой вопрос — такой ответ. Хотите visually lossless — соблюдайте заветы торентоблядей. x264, пердолинг с параметрами на уровне пресета placebo и битрейты как половина от блюрея ждут вас.
Хотите сжатия? Минимального размера при максимальной эффективности? Тогда выбирайте подходящий для вас CRF, устраивающий вас пресет или --cpu-used, и вперёд. И не надо ни у кого спрашивать, какой CRF лучше. Сам сравни и выбери наилучший для тебя.
> Или это беспонтовая затея уровня "конвертировать из lossy MP3 в другой lossy-формат"?
Именно.
>>09345
Какой вопрос — такой ответ. Хотите visually lossless — соблюдайте заветы торентоблядей. x264, пердолинг с параметрами на уровне пресета placebo и битрейты как половина от блюрея ждут вас.
Хотите сжатия? Минимального размера при максимальной эффективности? Тогда выбирайте подходящий для вас CRF, устраивающий вас пресет или --cpu-used, и вперёд. И не надо ни у кого спрашивать, какой CRF лучше. Сам сравни и выбери наилучший для тебя.
>>09462
Я не смотрю видео с мобилы.
Я не смотрю видео с мобилы.
Опять болезные пытаются svt-av1 сравнивать с какой-то хуйней, когда в прошлом тренде уже доказали, что при одинаковом времени кодирования svt-av1 сосёт хуй у aom.
trac.ffmpeg.org перестал открываться.
>>09509
Инфа из прошлого треда.
Инфа из прошлого треда.
>>09501
У aom есть пресеты? А что ещё у него есть? Хочу увидеть документацию по всем параметрам.
>Пресет 8 в aom
У aom есть пресеты? А что ещё у него есть? Хочу увидеть документацию по всем параметрам.
163 Кб, 1280x1155Перепробовал многие кодеки, и пришёл к выводу, что единственный хороший из них - пикрилейтед. В конце своих скитаний и напрасно потраченного времени вы это поймёте.
>>09513
Когда у тебя бан в гугле истекает?
https://github.com/AOMediaCodec/community/wiki/Advanced-Command-Line-Options
https://ffmpeg.org/ffmpeg-codecs.html#libaom_002dav1
Когда у тебя бан в гугле истекает?
https://github.com/AOMediaCodec/community/wiki/Advanced-Command-Line-Options
https://ffmpeg.org/ffmpeg-codecs.html#libaom_002dav1
>>09516
Ну и где там "preset"? Поиск на странице дал 0 результатов, нет там этого слова.
Не открывается.
Ну и где там "preset"? Поиск на странице дал 0 результатов, нет там этого слова.
>ffmpeg.org
Не открывается.
как ускорить кучу мп3-файлов в 2 раза чтобы они не начали пищать как будто гелия надышались?
>>09515
Хороший кодек. Но я бы предпочитаю кодек WD.
Хороший кодек. Но я бы предпочитаю кодек WD.
>>09515
А как таким кодеком шебмы на 2ch.hk заливать?
А как таким кодеком шебмы на 2ch.hk заливать?
Ну что же, давайте подумаем, где какой кодек, и какой из них лучше. Слева сверху, очевидно, сурс. На пикчах одни и те же кодеки расположены одинаково, т.е. справа сверху всегда один и тот же кодек.
Варианты для угадывания:
libsvtav1 c -preset 4
libaom-av1 с -cpu-used 8
libsvtav1 c -preset 5
Ссылка на запароленный архив, в котором содержится информация о том, где какой скрин и какие конкретно команды использовались, а так же затраченное время:
https://litter.catbox.moe/4vdayc.7z
Сегодня в 22:00 по МСК скину пароль. Или завтра, смотря как получится.
Варианты для угадывания:
libsvtav1 c -preset 4
libaom-av1 с -cpu-used 8
libsvtav1 c -preset 5
Ссылка на запароленный архив, в котором содержится информация о том, где какой скрин и какие конкретно команды использовались, а так же затраченное время:
https://litter.catbox.moe/4vdayc.7z
Сегодня в 22:00 по МСК скину пароль. Или завтра, смотря как получится.
>>09581
И в качестве бонуса, вот еще сурс, пожатый x264 с пресетом плацебо.
И в качестве бонуса, вот еще сурс, пожатый x264 с пресетом плацебо.
>>09475
При одинаковом времени кодирования aom не работает. Можешь показать при каких настройках aom сможет кодировать 1280х720х60 в реальном времени? Или хотя бы со скоростью 0.5?
>что при одинаковом времени кодирования
При одинаковом времени кодирования aom не работает. Можешь показать при каких настройках aom сможет кодировать 1280х720х60 в реальном времени? Или хотя бы со скоростью 0.5?
452 Кб, 1080x1642>>09583
Болезный, тебе зачем на процессоре av1 кодировать в реалтайме? Жди хардверных энкодеров на видеокартах, ими и кодируй с большими битрейтами, если до пизды нужно кодировать в ав1. А что же касается непосредственно вопроса, то aom не может кодировать в реалтайме. А то, что кодирует в реалтайме svt - мыло мыльнейшее.
Болезный, тебе зачем на процессоре av1 кодировать в реалтайме? Жди хардверных энкодеров на видеокартах, ими и кодируй с большими битрейтами, если до пизды нужно кодировать в ав1. А что же касается непосредственно вопроса, то aom не может кодировать в реалтайме. А то, что кодирует в реалтайме svt - мыло мыльнейшее.
>>09584
Чтобы ты спросил.
Чтобы ты спросил.
>>09585
Меня не интересуют кодеры работающие со скоростью меньше 0.3.
Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.
Всё ещё лучше реалтаймовых vp9/h264/h265 при том же битрейте.
Меня не интересуют кодеры работающие со скоростью меньше 0.3.
Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.
>мыло мыльнейшее.
Всё ещё лучше реалтаймовых vp9/h264/h265 при том же битрейте.
>>09581
ты хочешь что у людей глаза к хуям вытекли. Пики говно. Нах на мыльном говниме сравнить, тем более без деталей,
>3
ты хочешь что у людей глаза к хуям вытекли. Пики говно. Нах на мыльном говниме сравнить, тем более без деталей,
5,7 Мб, webm,480x480, 2:17
>>09575
спасибо, теперь буду превращать дум-метал в танцевальную музыку.
спасибо, теперь буду превращать дум-метал в танцевальную музыку.
>>09581
Ну что, давайте присвоим этим секциям номер, слева-направо сверху-вниз
Про кадр 1: секция 2 пожата наиболее грубо, ставлю на пресет 5. Секция 4 пожата получше, но всё ещё грубо. Ставлю на пресет 4. Лучше всего выглядит как по мне секция 3, ставлю на libaom.
Кадр 2: ты включил Grain syntesis? Но он здесь не нужен. В исходнике нету шумов, только градиенты. Соответственно наиболее выигрышной стратегией будет просто дать ему замылить, может так он сделает градиенты ещё плавнее и удалит наконец этот бандинг.
Кадр 3: в секции 2 я отчётливо вижу артефакты работы такой фишки AV1 как восстановление цвета из яркостного канала. Прям блоки резко меняющихся цветов повылазили. Ничего не изменилось, ставки по прежнему на 5-м пресете.
Между кадром в 4-й и 3-й секции разницы беглым взглядом не вижу. Ставки не меняються, просто как факт что разница не очевидна.
Кадр 4: бандинг, бандинг, бандинг. Везде бандинг кроме исходника. Скажи честно, ты его в 8 бит сжимал? Впрочем, даже если в 10, не удивлюсь. Но с этим бандингом надо бороться. Даже не знаю как это сделать не раздувая битрейт. Я даже сомневаюсь что 12 бит уберет бандинг. Может сгладит границы, и контуры цветовых переходов станут выглядеть аккуратнее, но вот как забороть бандинг насовсем не знаю.
Ну что, давайте присвоим этим секциям номер, слева-направо сверху-вниз
Про кадр 1: секция 2 пожата наиболее грубо, ставлю на пресет 5. Секция 4 пожата получше, но всё ещё грубо. Ставлю на пресет 4. Лучше всего выглядит как по мне секция 3, ставлю на libaom.
Кадр 2: ты включил Grain syntesis? Но он здесь не нужен. В исходнике нету шумов, только градиенты. Соответственно наиболее выигрышной стратегией будет просто дать ему замылить, может так он сделает градиенты ещё плавнее и удалит наконец этот бандинг.
Кадр 3: в секции 2 я отчётливо вижу артефакты работы такой фишки AV1 как восстановление цвета из яркостного канала. Прям блоки резко меняющихся цветов повылазили. Ничего не изменилось, ставки по прежнему на 5-м пресете.
Между кадром в 4-й и 3-й секции разницы беглым взглядом не вижу. Ставки не меняються, просто как факт что разница не очевидна.
Кадр 4: бандинг, бандинг, бандинг. Везде бандинг кроме исходника. Скажи честно, ты его в 8 бит сжимал? Впрочем, даже если в 10, не удивлюсь. Но с этим бандингом надо бороться. Даже не знаю как это сделать не раздувая битрейт. Я даже сомневаюсь что 12 бит уберет бандинг. Может сгладит границы, и контуры цветовых переходов станут выглядеть аккуратнее, но вот как забороть бандинг насовсем не знаю.
>>09575
А scaletempo2?
А scaletempo2?
>>09610
О каком баттле идёт речь? Как всегда, VVC aka H.266 займёт место на 8K HDR блуреях, а AV1 как свободный от патентов на YT/интернет видео. AV1 нужно скорее с H.265 сравнивать, который, к слову, уже внедрили в Сафари и в Хром. Спустя 10 лет может и выкатят кодек, который сопоставим с VVC, но сейчас мощи H.265 избыточны. AV1 как был свободным мыльцом так и останется, не в тот состоянии, чтобы с проприетарными кодеками тягаться.
> исхода баттла VVC vs AV1
О каком баттле идёт речь? Как всегда, VVC aka H.266 займёт место на 8K HDR блуреях, а AV1 как свободный от патентов на YT/интернет видео. AV1 нужно скорее с H.265 сравнивать, который, к слову, уже внедрили в Сафари и в Хром. Спустя 10 лет может и выкатят кодек, который сопоставим с VVC, но сейчас мощи H.265 избыточны. AV1 как был свободным мыльцом так и останется, не в тот состоянии, чтобы с проприетарными кодеками тягаться.
>>09589
У тебя неправильная формула. Стоимость транскодирования определяется по формуле:
стоимость транскодирования = время затраченное на транскодирование / (объём информации * срок хранения информации).
Иначе говоря, если ты хочешь сохранить значительный объём информации на долгий срок, то транскодирование безусловно выгодно.
Например, у тебя есть 200 Гб видео, которое ты хочешь сохранить у себя навсегда. Допустим тебе придётся затратить месяц на транскодирование всех этих видео. Что выгоднее, транскодировать месяц и получить 100 Гб информации заместо 200 Гб, которые ты будешь хранить годами, или таскать с собой все 200 Гб переливая их с одного HDD на другой + регулярные бекапы на чёрный день?
> Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.
У тебя неправильная формула. Стоимость транскодирования определяется по формуле:
стоимость транскодирования = время затраченное на транскодирование / (объём информации * срок хранения информации).
Иначе говоря, если ты хочешь сохранить значительный объём информации на долгий срок, то транскодирование безусловно выгодно.
Например, у тебя есть 200 Гб видео, которое ты хочешь сохранить у себя навсегда. Допустим тебе придётся затратить месяц на транскодирование всех этих видео. Что выгоднее, транскодировать месяц и получить 100 Гб информации заместо 200 Гб, которые ты будешь хранить годами, или таскать с собой все 200 Гб переливая их с одного HDD на другой + регулярные бекапы на чёрный день?
>>09603
Ты ещё пятый кадр пропустил, он постом ниже.
Да, все видео были сжаты в 8 бит, и на то, что я не пожал в 10 бит, есть несколько причин.
Первая заключается в том, что я не очень уверен, что большинство браузеров и аппаратных кодеков умеют (будут уметь) декодировать 10 бит ав1.
Вторая заключается в том, что мы сравниваем между собой не исходник с кодеком, а кодек с кодеком. Из этого вытекает, что если битность одинаковая, то разницы по качеству из-за несовпадающей битности в этом случае быть не должно. Но я внутрь не лез, так что это может быть притянуто за уши. Один кодек может утилизировать 10 бит лучше, чем другой. Или наоборот, какой-то кодек лучше себя проявляет именно в 8 бит.
И третья следует из второй, чтобы посмотреть на реальную разницу между 10 бит и 8 бит с разными пресетами и энкодерами, нужно было бы делать ещё больше тестовых картинок, на что ни я, ни файловые лимиты на доске ещё пока не готовы.
>>09616
Увы, у меня таких футажей нет, откуда брать - не знаю, а сервисами со стоками я не пользуюсь.
Ты ещё пятый кадр пропустил, он постом ниже.
>Скажи честно, ты его в 8 бит сжимал?
Да, все видео были сжаты в 8 бит, и на то, что я не пожал в 10 бит, есть несколько причин.
Первая заключается в том, что я не очень уверен, что большинство браузеров и аппаратных кодеков умеют (будут уметь) декодировать 10 бит ав1.
Вторая заключается в том, что мы сравниваем между собой не исходник с кодеком, а кодек с кодеком. Из этого вытекает, что если битность одинаковая, то разницы по качеству из-за несовпадающей битности в этом случае быть не должно. Но я внутрь не лез, так что это может быть притянуто за уши. Один кодек может утилизировать 10 бит лучше, чем другой. Или наоборот, какой-то кодек лучше себя проявляет именно в 8 бит.
И третья следует из второй, чтобы посмотреть на реальную разницу между 10 бит и 8 бит с разными пресетами и энкодерами, нужно было бы делать ещё больше тестовых картинок, на что ни я, ни файловые лимиты на доске ещё пока не готовы.
>>09616
Увы, у меня таких футажей нет, откуда брать - не знаю, а сервисами со стоками я не пользуюсь.
если верить сайту амд моя видеокарта поддерживает аппаратное кодирование h265 https://www.amd.com/en/products/graphics/amd-radeon-rx-6600-xt но когда я пытаюсь кодировать получается зелёный экран и наверху какие-то ошмётки от видео. с чем это может быть связано?
>>09632
Должны, ибо находятся в одном и том-же профиле — стандартном. Лишь для 12 бит нужно активировать high profile.
И как я уже сказал, с бандингом нужно бороться. И 10 битный режим значительно уменьшает бандинг. Это я про 12 бит сказал что он может и не устранить бандинг насовсем, но тут уже вопрос делает ли декодер RGB дизеринг.
> Первая заключается в том, что я не очень уверен, что большинство браузеров и аппаратных кодеков умеют (будут уметь) декодировать 10 бит ав1.
Должны, ибо находятся в одном и том-же профиле — стандартном. Лишь для 12 бит нужно активировать high profile.
И как я уже сказал, с бандингом нужно бороться. И 10 битный режим значительно уменьшает бандинг. Это я про 12 бит сказал что он может и не устранить бандинг насовсем, но тут уже вопрос делает ли декодер RGB дизеринг.
>>09581
Только один пока решился расписать что-то, видимо придется ждать до завтра.
Только один пока решился расписать что-то, видимо придется ждать до завтра.
>>09663
А если меня не интересуют отчетливые голоса на битрейтах картошки, а интересует сохранность всех слышимых деталей до 20-22 кГц, какой мне кодек звука использовать?
А если меня не интересуют отчетливые голоса на битрейтах картошки, а интересует сохранность всех слышимых деталей до 20-22 кГц, какой мне кодек звука использовать?
>>09712
Ну и зачем тебе этот кодек когда он ещё толком ничем не поддерживается?
Есть Opus, есть AAC, есть Vorbis в конце концов. Выбирай любой который тебе больше нравиться.
Ну и зачем тебе этот кодек когда он ещё толком ничем не поддерживается?
Есть Opus, есть AAC, есть Vorbis в конце концов. Выбирай любой который тебе больше нравиться.
Раньше тоже ебался с этими кодеками, кодировал там что-то. Потом со временем как начал работать вставил себе несколько терабайт и больше не ебусь с этим.
Че там сча по совместимости с аудиокодеками? Когда конверчу в мп3 то на 100% уверен что смогу воспроизвести везде.
С аас и огг также? Кто из них пизже? Для огг aotuv еще актуален или есть что-то пизже? Или может уже оригинальный libvorbis не хуже?
У опуса я так понял до сих пор плохая совместимость? Что-то круче него не придумали еще?
С аас и огг также? Кто из них пизже? Для огг aotuv еще актуален или есть что-то пизже? Или может уже оригинальный libvorbis не хуже?
У опуса я так понял до сих пор плохая совместимость? Что-то круче него не придумали еще?
>>09737
У AAC почти так-же. AAC не поддерживают только китайские MP3 плееры, китайские наушники с функцией mp3 плеера, ну и какой-нибудь музейный раритет. Даже старые кнопочные телефоны поддерживают AAC LC.
Opus открывается на любом более менее актуальном смартфоне. Если у тебя остался старый едва работающий смартфон на Android 4 и младше, то у тебя есть выбор между AAC и Vorbis.
У AAC почти так-же. AAC не поддерживают только китайские MP3 плееры, китайские наушники с функцией mp3 плеера, ну и какой-нибудь музейный раритет. Даже старые кнопочные телефоны поддерживают AAC LC.
Opus открывается на любом более менее актуальном смартфоне. Если у тебя остался старый едва работающий смартфон на Android 4 и младше, то у тебя есть выбор между AAC и Vorbis.
>>09737
В пизде.
Обзаведись портативным устройством под бюджет, софтовым плеером на вкус, и будет тебе настоящее везде. Mp3 по факту устарел, ему не место в 2022 году ни под каким соусом. Гоните и насмехайтесь над теми, кто в него сжимает. Не место, так же как и огрызкам, которые ничего современные не поддерживают.
>везде
В пизде.
Обзаведись портативным устройством под бюджет, софтовым плеером на вкус, и будет тебе настоящее везде. Mp3 по факту устарел, ему не место в 2022 году ни под каким соусом. Гоните и насмехайтесь над теми, кто в него сжимает. Не место, так же как и огрызкам, которые ничего современные не поддерживают.
>>09581
Пароль от архива: 0a7DA6B4IjN7R2P28jQ7Tq0u52B2BeJF
Всем прочитавшим, но проигнорировавшим чмоням желаю плохих снов. Получилась отличная выборка из одного человека. Дублирую для самых ленивых (почти всех) содержание архива:
Слева сверху оригинал.
Справа сверху libaom-av1 с -cpu-used 8
Слева снизу libsvtav1 c -preset 4
Справа снизу libsvtav1 с -preset 5
Изображение с лицом - контрольное, оно не сжималось кодеками, все 3 картинки шакалились с помощью одних и тех же фильтров фотошопа.
libaom-av1 с -cpu-used 8 кодировался 06:29
libsvtav1 c -preset 4 кодировался 11:49
libsvtav1 c -preset 5 кодировался 06:07
Полные команды:
ffmpeg -hide_banner -i in.mkv -pass 1 -passlogfile passlog -c:v libaom-av1 -cpu-used 8 -tile-columns 4 -b:v 488.3k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -an -f null nul
ffmpeg -hide_banner -i in.mkv -pass 2 -passlogfile passlog -c:v libaom-av1 -cpu-used 8 -tile-columns 4 -b:v 488.3k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -c:a libopus -b:a 128k libaom-av1-8.webm
ffmpeg -hide_banner -i in.mkv -c:v libsvtav1 -preset 4 -g 128 -b:v 488.3k -c:a libopus -b:a 128k libsvtav1-4.webm
ffmpeg -hide_banner -i in.mkv -c:v libsvtav1 -preset 5 -g 128 -b:v 488.3k -c:a libopus -b:a 128k libsvtav1-5.webm
Пароль от архива: 0a7DA6B4IjN7R2P28jQ7Tq0u52B2BeJF
Всем прочитавшим, но проигнорировавшим чмоням желаю плохих снов. Получилась отличная выборка из одного человека. Дублирую для самых ленивых (почти всех) содержание архива:
Слева сверху оригинал.
Справа сверху libaom-av1 с -cpu-used 8
Слева снизу libsvtav1 c -preset 4
Справа снизу libsvtav1 с -preset 5
Изображение с лицом - контрольное, оно не сжималось кодеками, все 3 картинки шакалились с помощью одних и тех же фильтров фотошопа.
libaom-av1 с -cpu-used 8 кодировался 06:29
libsvtav1 c -preset 4 кодировался 11:49
libsvtav1 c -preset 5 кодировался 06:07
Полные команды:
ffmpeg -hide_banner -i in.mkv -pass 1 -passlogfile passlog -c:v libaom-av1 -cpu-used 8 -tile-columns 4 -b:v 488.3k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -an -f null nul
ffmpeg -hide_banner -i in.mkv -pass 2 -passlogfile passlog -c:v libaom-av1 -cpu-used 8 -tile-columns 4 -b:v 488.3k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -c:a libopus -b:a 128k libaom-av1-8.webm
ffmpeg -hide_banner -i in.mkv -c:v libsvtav1 -preset 4 -g 128 -b:v 488.3k -c:a libopus -b:a 128k libsvtav1-4.webm
ffmpeg -hide_banner -i in.mkv -c:v libsvtav1 -preset 5 -g 128 -b:v 488.3k -c:a libopus -b:a 128k libsvtav1-5.webm
>>09899
То есть я не угадал ни в одном из случаев.
Худшим оказался libaom с cpu-used 8. Отличное разоблачение мифа, однако.
Лучшим оказался svt1av1 с пресетом 4, что в общем то логично. Кстати, нужно сравнить svtav1 preset 4 с aomenc cpu-used 4 запущенным через av1an.
То есть я не угадал ни в одном из случаев.
Худшим оказался libaom с cpu-used 8. Отличное разоблачение мифа, однако.
Лучшим оказался svt1av1 с пресетом 4, что в общем то логично. Кстати, нужно сравнить svtav1 preset 4 с aomenc cpu-used 4 запущенным через av1an.
>>09714
Чем он лучше опуса?
Чем он лучше опуса?
Я не пойму vvc вышел или нет, можно в него покодировать, какая производительность? Пока что компилирую и посмотрю что да как.
>>10111
Кодировать можно, а декодировать - хуй. Поэтому
Нет, не вышел.
>можно в него покодировать
Кодировать можно, а декодировать - хуй. Поэтому
>Я не пойму vvc вышел или нет
Нет, не вышел.
>>10116
Да ну. Есть же софтверный плеер какой-нибудь. Хотя пока в ffmpeg не запихнут, так и не будет наверное. Потому что почти все плееры юзают ffmpeg.
Посмотрел, вышел то еще в 2020 по сути. https://github.com/fraunhoferhhi/vvenc. Уже версия 1.6.
Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.
>Кодировать можно, а декодировать - хуй. Поэтому
Да ну. Есть же софтверный плеер какой-нибудь. Хотя пока в ffmpeg не запихнут, так и не будет наверное. Потому что почти все плееры юзают ffmpeg.
>Нет, не вышел.
Посмотрел, вышел то еще в 2020 по сути. https://github.com/fraunhoferhhi/vvenc. Уже версия 1.6.
Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.
>>10121
"Какой-нибудь" - ключевое слово. По факту никакой. Ни mpv, ни ffmpeg, ни конусы и дауны, вангую, тоже.
А потом что? Чем открывать будешь?
>Есть же софтверный плеер какой-нибудь
"Какой-нибудь" - ключевое слово. По факту никакой. Ни mpv, ни ffmpeg, ни конусы и дауны, вангую, тоже.
>Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.
А потом что? Чем открывать будешь?
>>10122
vlc плагин какой-то есть https://code.videolan.org/videolan/vlc/-/issues/27055
но у меня не получается его завести
есть еще tencent O266, но мне лень компилить сурс с помощью докера.
Беда прям какая-то, за 2 года могли и допилить.
vlc плагин какой-то есть https://code.videolan.org/videolan/vlc/-/issues/27055
но у меня не получается его завести
есть еще tencent O266, но мне лень компилить сурс с помощью докера.
Беда прям какая-то, за 2 года могли и допилить.
>>10125
Куда спешишь? Расслабься, не уйдёт от тебя нескодированное видео, скодируешь, когда будут декодеры.
Куда спешишь? Расслабься, не уйдёт от тебя нескодированное видео, скодируешь, когда будут декодеры.
79 Кб, 1278x498>>10126
Так я уже скодировал. 2 секунды в 60 фпс, 210 фреймов. Судя по гитхабу пресет slow чуть медленнее пресета x265 placebo. В общем, у них там работа ведется, и кодек реально очень хорошо оптимизируется, в сравнении с прошлыми версиями.
Можно сбилдить vlc с поддержкой vvdec, но снова лень чет разворачивать всё.
Так я уже скодировал. 2 секунды в 60 фпс, 210 фреймов. Судя по гитхабу пресет slow чуть медленнее пресета x265 placebo. В общем, у них там работа ведется, и кодек реально очень хорошо оптимизируется, в сравнении с прошлыми версиями.
Можно сбилдить vlc с поддержкой vvdec, но снова лень чет разворачивать всё.
>>10130
хз скомпилить самому с libvvdec
хз скомпилить самому с libvvdec
25 Кб, 435x92> If you read the VVenC line across, you see that VVenC delivered a 39% efficiency gain over x265, which is in line with the test model and impressive, but was only 11% more efficient than AV1.
Ну и кому нужен такой кодек? Гуглу такой кодек точно не нужен. Есть варианты?
>>10169
Получается, что av1 эффективнее x265? Ну, по личным наблюдениям, транскод в x265 даёт очень хорошую сохранность деталям при небольшом уменьшении размера, а av1, как ты не пыхти, будет мылом, но весит мало. Хотя в некоторых сценах и с некоторым материалом av1 не показывает никакой потери деталей, только убирает шум (шум=избыточность).
Получается, что av1 эффективнее x265? Ну, по личным наблюдениям, транскод в x265 даёт очень хорошую сохранность деталям при небольшом уменьшении размера, а av1, как ты не пыхти, будет мылом, но весит мало. Хотя в некоторых сценах и с некоторым материалом av1 не показывает никакой потери деталей, только убирает шум (шум=избыточность).
>>10171
x265 выглядит чётче потому-что там предусмотрены специальные психовизуальные оптимизации которые увеличивают погрешность при кодировании, но улучшают восприятие картинки. Мне эти оптимизации уже выходили боком, когда я кодировал плавные градиенты на тёмном фоне, они превращались в блочно пиксельное нечто — пришлось вручную уменьшать psy-rd.
У aomenc с этими техниками беда — он по дефолту тюнит под PSNR, а с другими метриками у него какие-то непонятки: то их надо включать в билд, то они замедляют кодирование… Говорят есть ещё форк psyaom, не помню как именно он назывался, но мне лень пердолиться с ним, тем более что меня и ванильный aomenc устраивает.
x265 выглядит чётче потому-что там предусмотрены специальные психовизуальные оптимизации которые увеличивают погрешность при кодировании, но улучшают восприятие картинки. Мне эти оптимизации уже выходили боком, когда я кодировал плавные градиенты на тёмном фоне, они превращались в блочно пиксельное нечто — пришлось вручную уменьшать psy-rd.
У aomenc с этими техниками беда — он по дефолту тюнит под PSNR, а с другими метриками у него какие-то непонятки: то их надо включать в билд, то они замедляют кодирование… Говорят есть ещё форк psyaom, не помню как именно он назывался, но мне лень пердолиться с ним, тем более что меня и ванильный aomenc устраивает.
>>10169
Что это за пиздец? На каком разрешении, на каких скоростях и прочая и прочая
А кому нужно что-то выше h264? Тем, у кого проблемки с шириной канала(ограничение на размер прикрепа в посте)/сверхвысокие разрешения, в которых h264 не эффективен, ввиду малого размера блоков, для 1080p это всё пустое баловство и 60% большей эффективности, при сравнимом качестве и адекватном битрейте там наберётся едва ли.
Что это за пиздец? На каком разрешении, на каких скоростях и прочая и прочая
> Ну и кому нужен такой кодек
А кому нужно что-то выше h264? Тем, у кого проблемки с шириной канала(ограничение на размер прикрепа в посте)/сверхвысокие разрешения, в которых h264 не эффективен, ввиду малого размера блоков, для 1080p это всё пустое баловство и 60% большей эффективности, при сравнимом качестве и адекватном битрейте там наберётся едва ли.
>>10169
Что vp9, что av1 мылит я ебал. Даже в 4:4:4 деталей не остается, в сравнении с x264.
Что vp9, что av1 мылит я ебал. Даже в 4:4:4 деталей не остается, в сравнении с x264.
>>10191
чел это тесты с декабря 20 года, после 2-3 месяцов выхода vvc.
https://github.com/fraunhoferhhi/vvenc/wiki/Encoder-Performance
чел это тесты с декабря 20 года, после 2-3 месяцов выхода vvc.
https://github.com/fraunhoferhhi/vvenc/wiki/Encoder-Performance
>>10182
Про психовизуальное восприятие не знал. Градиенты не кодировал, сказать не могу.
PSNR весит чуть меньше, но на глаз ощутимо хуже чем VQ (--tune 0). Я ещё удивился, почему его по дефолту не ставят.
метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.
Разве?
Не слышал о таком. Малопопулярные форки доставляют много проблем - мало кто ловит ошибки в них и проводит тесты.
Про психовизуальное восприятие не знал. Градиенты не кодировал, сказать не могу.
>он по дефолту тюнит под PSNR
PSNR весит чуть меньше, но на глаз ощутимо хуже чем VQ (--tune 0). Я ещё удивился, почему его по дефолту не ставят.
>а с другими метриками
метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.
>то они замедляют кодирование
Разве?
>Говорят есть ещё форк psyaom
Не слышал о таком. Малопопулярные форки доставляют много проблем - мало кто ловит ошибки в них и проводит тесты.
>>10196
Я про aomenc, если что.
> метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.
Я про aomenc, если что.
>>05384 (OP)
Для чего они предназначены?
> https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
> CQ и остальные выглядят хуже потому что предназначены для другого и поэтому не рекомендуются!
Для чего они предназначены?
>>11108
Если crf повышает значение в динамичных сценах, то почему в них наоборот выше битрейт, чем в статичных?
Если crf повышает значение в динамичных сценах, то почему в них наоборот выше битрейт, чем в статичных?
>>11198
Тогда это будет режим с постоянным квантователем, и весить такой файл будет больше.
Тогда это будет режим с постоянным квантователем, и весить такой файл будет больше.
>>05384 (OP)
Ты сам разбирался, что они значат, или просто на авторитетный источник ссылаешься (он не открывается, кстати)? Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше при прочих равных. По качеству никакой разницы, всё равно CRF 35.
> https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
> Указаны два параметра которые рекомендуются в руководстве для повышения качества видео.
Ты сам разбирался, что они значат, или просто на авторитетный источник ссылаешься (он не открывается, кстати)? Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше при прочих равных. По качеству никакой разницы, всё равно CRF 35.
>>11217
В смысле не открывается
Ну да, ссылаюсь. Параметры из документаций официальных набирал, и по опыту.
Серьёзно, можешь показать пример? Странно
В смысле не открывается
Ну да, ссылаюсь. Параметры из документаций официальных набирал, и по опыту.
> Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше
Серьёзно, можешь показать пример? Странно
можно ли сделать красивый плейлист в виде
Album
[04:20] 1. Artist - Song
с помощью ffprobe или ffmpeg?
Album
[04:20] 1. Artist - Song
с помощью ffprobe или ffmpeg?
>>11326
ХЗ. Тут с регулярками баловаться надо, а где и как это делать что-бы получить текстовик не знаю.
ХЗ. Тут с регулярками баловаться надо, а где и как это делать что-бы получить текстовик не знаю.
>>3199130 →
Да не было там ни хуя.
(Или покажи, где он был.)
>>3201419 →
Значит, но при определённом (не слишком сложном) подсчёте разницы, который ограничивается чистым вычитанием.
Поэтому опора на этот метод при видеосжатии даёт результаты похуже тѣхъ, которые пытаются считать ещё реальную замѣтность разницы (которая зависит не только от ея величины).
>>3201460 →
Не нормально; но ужé, к нашему счастью, было исправлено разработчиками.
>>3201691 →
Работу кодировщика lossless JPEG XL разработчики ещё не довели до такого уровня, чтобы он ВСЕГДА опережал lossless WebP (хотя теоретически такое ≈возможно).
Поэтому после перекодирования ещё провѣряйте, не распух ли файл по объёму.
>>3201703 →
Думаю, что на катастрофически низком битрейте AVIF чуточку лучше выглядит.
(JPEG XL начинает «извилисто ломать» косые отрѣзки линий, напримѣръ.
Квадратики макроблоков кодирования также становятся раздражающе видными.)
>>3201850 →
Google воспринимает минус перед словом как оператор отрицания.
(То есть поиск «Иващенко -лимон» ищет только такие страницы про различных Иващенко, которые составлены без упоминания лимонов.)
>>3202778 →
XnView MP
>>3205312 →
Поясните, почему нельзя было вызвать FFmpeg один раз?
ffmpeg -hide_banner -i "sourcefile.mkv" -sn -map_metadata -1 -map_chapters -1 -b:v 0 -c:v libsvtav1 -crf 19 -svtav1-params keyint=1s:film-grain=8:lookahead=120:hierarchical-levels=5:tune=0 -preset 5 -strict -1 -pix_fmt yuv420p10le -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile (svtav1).mkv"
Сразу скажу ещё, что односекундный интервал между ключевыми кадрами представляется маловатым.
Сразу скажу ещё, что без «-strict -1» можно, кажись, обойтись.
>>08639
>>3205319 →
Раз с с математическо-программистической, то сейчас будут заумныя разсужденія.
(Но не такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется.)
Опосля первого появления десятибитности цвѣтовыхъ компонентов в видеофайлах (рѣчь идёт о появлении профиля «High 10» в рекомендациях ITU-T, это было в марте 2005 года) достаточно быстро (в течение нѣсколькихъ лѣтъ) сдѣлалось ясным, что такие видеофайлы лучше подходят (чѣмъ прежние) не только для таких кадров, пикселы которых с сáмого начала и были тридцатибитными, но также и для 24-битных пикселов (TrueColor), состоящих из трёх восьмибитных (а не десятибитных) цвѣтовыхъ компонентов. (Ну, напримѣръ, понимание этого излагается по адресу https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf в таком PDF, который датирован 2010 годом.)
Вот как это устроено:
① Всякое видеокодирование происходит с внесением потерь в кадры.
② Часть алгоритмов видеокодирования устроена таким образом, что их намѣреніемъ является именно внесение потерь в кадры (съ цѣлью сжатия видеоданных). Другая часть алгоритмов (напримѣръ, преобразование кадров или предсказание одних кадров на основе других кадров), напротив, стремится к точности; потери в таких алгоритмах также вносятся, но в силу погрѣшностей, и алгоритмы устроены таким образом, чтобы свести погрѣшности к минимуму.
③ Понятие «погрѣшность невелика» математически означает «погрѣшность сосредоточена в немногих младших разрядах числа» (скажем, в одном-двух младших разрядах).
④ Построение восьмибитных компонентов цвѣта (для реального экранного пиксела на восьмибитном экране) на основе десятибитных компонентов цвѣта (содержащихся в видеофайле) как раз и сводится к отбрасыванию двух младших разрядов каждого компонента — слѣдовательно, таким отбрасыванием устраняются и всѣ погрешности видеокодирования, сосредоточенные (полностью или хотя бы главным образом) в этих разрядах.
⑤ Первоначальное же построение десятибитных компонентов цвѣта (содержащихся в видеофайле) на основе восьмибитных компонентов цвѣта (содержащихся в исходных кадрах видеозаписи) сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов.
⑥ Благодаря двум вышеупомянутым факторам (большей аккуратности видеосжатия и большой первоначальной избыточности видеоданных) происходит вот что: хотя объём видеофайла растёт при перехода к восьмибитности к десятибитности цвѣтовыхъ компонентов, соотношение качества файла и объёма растёт ещё быстрѣе — слѣдовательно, слегка понизив качество кодирования, можно и в прежний объём видеофайла засунуть видео большего качества.
Вот наглядные примѣры двух вышеупомянутых подвидов алгоритмов — вносящих погрѣшности (устранимые десятибитностью) и вносящих намѣренные потери данных:
⓵ Алгоритм преобразования пикселов из RGB въ цвѣторазностное пространство (и обратно) устроен таким образом, что порождает ошибки округления, которые устраняются, если преобразование происходит в большей разрядности (об этом говорит нам первый абзац по адресу https://en.wikipedia.org/wiki/YCbCr#Y'PbPr_to_Y'CbCr в Википедии).
⓶ Намѣреннымъ же внесением ошибок въ цвѣтность (отбрасыванием ¾ цвѣтовой информации в интересах видеосжатия) занимается при этом другой алгоритм, совершающий цвѣтовую субдискретизацию 4:2:0 (см. https://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 в Википедии).
Распробовав рост отношения качества видео к объёму файла, многие авторы видеофайлов вот ужé примѣрно лѣтъ пятнадцать стремятся создавать файлы с тридцатибитными пикселами.
>>08560
Поставь Media Player Classic Home Cinema (по адресу https://github.com/clsid2/mpc-hc/releases возьми).
>>09059
Потому что надо ставить не через «-g значение», а через «-svtav1-params keyint=20s».
Тогда к пониманию смысла подключится SVT-AV1 и будет всё ok.
>>09102
Не «:», а «=».
>>09133
Чего только не придумают люди, чтобы не пользоваться готовою встроенностью LAVFilters внутри Media Player Classic Home Cinema.
>>09475
У меня прекрасные новости для тебя и других подобных любителей хуесосных метафор.
Но эти новости и кого угодно порадуют.
По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2016#note_1119896397 ясно видно, что скорость работы SVT-AV1 под Windows только что ускорили ШЕСТИКРАТНО: в одном из примѣровъ было 0,178 кадра в секунду (на четвёртом пресете), а стало 1,087.
>>09667
Когда закончится срок дѣйствія патента.
Ждём до ≈2032 года.
> но там был патч
Да не было там ни хуя.
(Или покажи, где он был.)
>>3201419 →
> А это разве и не значит, что разница между исходным видео и полученным будет не выше определённой?
Значит, но при определённом (не слишком сложном) подсчёте разницы, который ограничивается чистым вычитанием.
Поэтому опора на этот метод при видеосжатии даёт результаты похуже тѣхъ, которые пытаются считать ещё реальную замѣтность разницы (которая зависит не только от ея величины).
>>3201460 →
> Кстати, это нормально, что оно
Не нормально; но ужé, к нашему счастью, было исправлено разработчиками.
>>3201691 →
> JPEG XL ещё эффективнее
Работу кодировщика lossless JPEG XL разработчики ещё не довели до такого уровня, чтобы он ВСЕГДА опережал lossless WebP (хотя теоретически такое ≈возможно).
Поэтому после перекодирования ещё провѣряйте, не распух ли файл по объёму.
>>3201703 →
> на катастрофически низком битрейте
Думаю, что на катастрофически низком битрейте AVIF чуточку лучше выглядит.
(JPEG XL начинает «извилисто ломать» косые отрѣзки линий, напримѣръ.
Квадратики макроблоков кодирования также становятся раздражающе видными.)
>>3201850 →
> Гугл не ищет.
Google воспринимает минус перед словом как оператор отрицания.
(То есть поиск «Иващенко -лимон» ищет только такие страницы про различных Иващенко, которые составлены без упоминания лимонов.)
>>3202778 →
> вменяемый просмотрщик изображений с поддержкой JXL
XnView MP
>>3205312 →
> Что думаете о моей команде для кодирования в SVT-AV1?
Поясните, почему нельзя было вызвать FFmpeg один раз?
ffmpeg -hide_banner -i "sourcefile.mkv" -sn -map_metadata -1 -map_chapters -1 -b:v 0 -c:v libsvtav1 -crf 19 -svtav1-params keyint=1s:film-grain=8:lookahead=120:hierarchical-levels=5:tune=0 -preset 5 -strict -1 -pix_fmt yuv420p10le -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile (svtav1).mkv"
Сразу скажу ещё, что односекундный интервал между ключевыми кадрами представляется маловатым.
Сразу скажу ещё, что без «-strict -1» можно, кажись, обойтись.
>>08639
> зачем и нахуя люди пилят 10 бит видео?
>>3205319 →
> Что такое 10 бит с математическо-программистической точки зрения?
Раз с с математическо-программистической, то сейчас будут заумныя разсужденія.
(Но не такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется.)
Опосля первого появления десятибитности цвѣтовыхъ компонентов в видеофайлах (рѣчь идёт о появлении профиля «High 10» в рекомендациях ITU-T, это было в марте 2005 года) достаточно быстро (в течение нѣсколькихъ лѣтъ) сдѣлалось ясным, что такие видеофайлы лучше подходят (чѣмъ прежние) не только для таких кадров, пикселы которых с сáмого начала и были тридцатибитными, но также и для 24-битных пикселов (TrueColor), состоящих из трёх восьмибитных (а не десятибитных) цвѣтовыхъ компонентов. (Ну, напримѣръ, понимание этого излагается по адресу https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf в таком PDF, который датирован 2010 годом.)
Вот как это устроено:
① Всякое видеокодирование происходит с внесением потерь в кадры.
② Часть алгоритмов видеокодирования устроена таким образом, что их намѣреніемъ является именно внесение потерь в кадры (съ цѣлью сжатия видеоданных). Другая часть алгоритмов (напримѣръ, преобразование кадров или предсказание одних кадров на основе других кадров), напротив, стремится к точности; потери в таких алгоритмах также вносятся, но в силу погрѣшностей, и алгоритмы устроены таким образом, чтобы свести погрѣшности к минимуму.
③ Понятие «погрѣшность невелика» математически означает «погрѣшность сосредоточена в немногих младших разрядах числа» (скажем, в одном-двух младших разрядах).
④ Построение восьмибитных компонентов цвѣта (для реального экранного пиксела на восьмибитном экране) на основе десятибитных компонентов цвѣта (содержащихся в видеофайле) как раз и сводится к отбрасыванию двух младших разрядов каждого компонента — слѣдовательно, таким отбрасыванием устраняются и всѣ погрешности видеокодирования, сосредоточенные (полностью или хотя бы главным образом) в этих разрядах.
⑤ Первоначальное же построение десятибитных компонентов цвѣта (содержащихся в видеофайле) на основе восьмибитных компонентов цвѣта (содержащихся в исходных кадрах видеозаписи) сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов.
⑥ Благодаря двум вышеупомянутым факторам (большей аккуратности видеосжатия и большой первоначальной избыточности видеоданных) происходит вот что: хотя объём видеофайла растёт при перехода к восьмибитности к десятибитности цвѣтовыхъ компонентов, соотношение качества файла и объёма растёт ещё быстрѣе — слѣдовательно, слегка понизив качество кодирования, можно и в прежний объём видеофайла засунуть видео большего качества.
Вот наглядные примѣры двух вышеупомянутых подвидов алгоритмов — вносящих погрѣшности (устранимые десятибитностью) и вносящих намѣренные потери данных:
⓵ Алгоритм преобразования пикселов из RGB въ цвѣторазностное пространство (и обратно) устроен таким образом, что порождает ошибки округления, которые устраняются, если преобразование происходит в большей разрядности (об этом говорит нам первый абзац по адресу https://en.wikipedia.org/wiki/YCbCr#Y'PbPr_to_Y'CbCr в Википедии).
⓶ Намѣреннымъ же внесением ошибок въ цвѣтность (отбрасыванием ¾ цвѣтовой информации в интересах видеосжатия) занимается при этом другой алгоритм, совершающий цвѣтовую субдискретизацию 4:2:0 (см. https://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 в Википедии).
Распробовав рост отношения качества видео к объёму файла, многие авторы видеофайлов вот ужé примѣрно лѣтъ пятнадцать стремятся создавать файлы с тридцатибитными пикселами.
>>08560
> встроенный в 11-е окна плеер не может его показать
Поставь Media Player Classic Home Cinema (по адресу https://github.com/clsid2/mpc-hc/releases возьми).
>>09059
> В ffmpeg ставить только по-старому, значением.
Потому что надо ставить не через «-g значение», а через «-svtav1-params keyint=20s».
Тогда к пониманию смысла подключится SVT-AV1 и будет всё ok.
>>09102
> keyint:10s
Не «:», а «=».
>>09133
> ставишь кодек лайт
Чего только не придумают люди, чтобы не пользоваться готовою встроенностью LAVFilters внутри Media Player Classic Home Cinema.
>>09475
> доказали, что при одинаковом времени кодирования svt-av1 сосёт хуй у aom
У меня прекрасные новости для тебя и других подобных любителей хуесосных метафор.
Но эти новости и кого угодно порадуют.
По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2016#note_1119896397 ясно видно, что скорость работы SVT-AV1 под Windows только что ускорили ШЕСТИКРАТНО: в одном из примѣровъ было 0,178 кадра в секунду (на четвёртом пресете), а стало 1,087.
>>09667
> Когда же декодер добавят в FFmpeg?
Когда закончится срок дѣйствія патента.
Ждём до ≈2032 года.
>>3199130 →
Да не было там ни хуя.
(Или покажи, где он был.)
>>3201419 →
Значит, но при определённом (не слишком сложном) подсчёте разницы, который ограничивается чистым вычитанием.
Поэтому опора на этот метод при видеосжатии даёт результаты похуже тѣхъ, которые пытаются считать ещё реальную замѣтность разницы (которая зависит не только от ея величины).
>>3201460 →
Не нормально; но ужé, к нашему счастью, было исправлено разработчиками.
>>3201691 →
Работу кодировщика lossless JPEG XL разработчики ещё не довели до такого уровня, чтобы он ВСЕГДА опережал lossless WebP (хотя теоретически такое ≈возможно).
Поэтому после перекодирования ещё провѣряйте, не распух ли файл по объёму.
>>3201703 →
Думаю, что на катастрофически низком битрейте AVIF чуточку лучше выглядит.
(JPEG XL начинает «извилисто ломать» косые отрѣзки линий, напримѣръ.
Квадратики макроблоков кодирования также становятся раздражающе видными.)
>>3201850 →
Google воспринимает минус перед словом как оператор отрицания.
(То есть поиск «Иващенко -лимон» ищет только такие страницы про различных Иващенко, которые составлены без упоминания лимонов.)
>>3202778 →
XnView MP
>>3205312 →
Поясните, почему нельзя было вызвать FFmpeg один раз?
ffmpeg -hide_banner -i "sourcefile.mkv" -sn -map_metadata -1 -map_chapters -1 -b:v 0 -c:v libsvtav1 -crf 19 -svtav1-params keyint=1s:film-grain=8:lookahead=120:hierarchical-levels=5:tune=0 -preset 5 -strict -1 -pix_fmt yuv420p10le -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile (svtav1).mkv"
Сразу скажу ещё, что односекундный интервал между ключевыми кадрами представляется маловатым.
Сразу скажу ещё, что без «-strict -1» можно, кажись, обойтись.
>>08639
>>3205319 →
Раз с с математическо-программистической, то сейчас будут заумныя разсужденія.
(Но не такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется.)
Опосля первого появления десятибитности цвѣтовыхъ компонентов в видеофайлах (рѣчь идёт о появлении профиля «High 10» в рекомендациях ITU-T, это было в марте 2005 года) достаточно быстро (в течение нѣсколькихъ лѣтъ) сдѣлалось ясным, что такие видеофайлы лучше подходят (чѣмъ прежние) не только для таких кадров, пикселы которых с сáмого начала и были тридцатибитными, но также и для 24-битных пикселов (TrueColor), состоящих из трёх восьмибитных (а не десятибитных) цвѣтовыхъ компонентов. (Ну, напримѣръ, понимание этого излагается по адресу https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf в таком PDF, который датирован 2010 годом.)
Вот как это устроено:
① Всякое видеокодирование происходит с внесением потерь в кадры.
② Часть алгоритмов видеокодирования устроена таким образом, что их намѣреніемъ является именно внесение потерь в кадры (съ цѣлью сжатия видеоданных). Другая часть алгоритмов (напримѣръ, преобразование кадров или предсказание одних кадров на основе других кадров), напротив, стремится к точности; потери в таких алгоритмах также вносятся, но в силу погрѣшностей, и алгоритмы устроены таким образом, чтобы свести погрѣшности к минимуму.
③ Понятие «погрѣшность невелика» математически означает «погрѣшность сосредоточена в немногих младших разрядах числа» (скажем, в одном-двух младших разрядах).
④ Построение восьмибитных компонентов цвѣта (для реального экранного пиксела на восьмибитном экране) на основе десятибитных компонентов цвѣта (содержащихся в видеофайле) как раз и сводится к отбрасыванию двух младших разрядов каждого компонента — слѣдовательно, таким отбрасыванием устраняются и всѣ погрешности видеокодирования, сосредоточенные (полностью или хотя бы главным образом) в этих разрядах.
⑤ Первоначальное же построение десятибитных компонентов цвѣта (содержащихся в видеофайле) на основе восьмибитных компонентов цвѣта (содержащихся в исходных кадрах видеозаписи) сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов.
⑥ Благодаря двум вышеупомянутым факторам (большей аккуратности видеосжатия и большой первоначальной избыточности видеоданных) происходит вот что: хотя объём видеофайла растёт при перехода к восьмибитности к десятибитности цвѣтовыхъ компонентов, соотношение качества файла и объёма растёт ещё быстрѣе — слѣдовательно, слегка понизив качество кодирования, можно и в прежний объём видеофайла засунуть видео большего качества.
Вот наглядные примѣры двух вышеупомянутых подвидов алгоритмов — вносящих погрѣшности (устранимые десятибитностью) и вносящих намѣренные потери данных:
⓵ Алгоритм преобразования пикселов из RGB въ цвѣторазностное пространство (и обратно) устроен таким образом, что порождает ошибки округления, которые устраняются, если преобразование происходит в большей разрядности (об этом говорит нам первый абзац по адресу https://en.wikipedia.org/wiki/YCbCr#Y'PbPr_to_Y'CbCr в Википедии).
⓶ Намѣреннымъ же внесением ошибок въ цвѣтность (отбрасыванием ¾ цвѣтовой информации в интересах видеосжатия) занимается при этом другой алгоритм, совершающий цвѣтовую субдискретизацию 4:2:0 (см. https://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 в Википедии).
Распробовав рост отношения качества видео к объёму файла, многие авторы видеофайлов вот ужé примѣрно лѣтъ пятнадцать стремятся создавать файлы с тридцатибитными пикселами.
>>08560
Поставь Media Player Classic Home Cinema (по адресу https://github.com/clsid2/mpc-hc/releases возьми).
>>09059
Потому что надо ставить не через «-g значение», а через «-svtav1-params keyint=20s».
Тогда к пониманию смысла подключится SVT-AV1 и будет всё ok.
>>09102
Не «:», а «=».
>>09133
Чего только не придумают люди, чтобы не пользоваться готовою встроенностью LAVFilters внутри Media Player Classic Home Cinema.
>>09475
У меня прекрасные новости для тебя и других подобных любителей хуесосных метафор.
Но эти новости и кого угодно порадуют.
По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2016#note_1119896397 ясно видно, что скорость работы SVT-AV1 под Windows только что ускорили ШЕСТИКРАТНО: в одном из примѣровъ было 0,178 кадра в секунду (на четвёртом пресете), а стало 1,087.
>>09667
Когда закончится срок дѣйствія патента.
Ждём до ≈2032 года.
> но там был патч
Да не было там ни хуя.
(Или покажи, где он был.)
>>3201419 →
> А это разве и не значит, что разница между исходным видео и полученным будет не выше определённой?
Значит, но при определённом (не слишком сложном) подсчёте разницы, который ограничивается чистым вычитанием.
Поэтому опора на этот метод при видеосжатии даёт результаты похуже тѣхъ, которые пытаются считать ещё реальную замѣтность разницы (которая зависит не только от ея величины).
>>3201460 →
> Кстати, это нормально, что оно
Не нормально; но ужé, к нашему счастью, было исправлено разработчиками.
>>3201691 →
> JPEG XL ещё эффективнее
Работу кодировщика lossless JPEG XL разработчики ещё не довели до такого уровня, чтобы он ВСЕГДА опережал lossless WebP (хотя теоретически такое ≈возможно).
Поэтому после перекодирования ещё провѣряйте, не распух ли файл по объёму.
>>3201703 →
> на катастрофически низком битрейте
Думаю, что на катастрофически низком битрейте AVIF чуточку лучше выглядит.
(JPEG XL начинает «извилисто ломать» косые отрѣзки линий, напримѣръ.
Квадратики макроблоков кодирования также становятся раздражающе видными.)
>>3201850 →
> Гугл не ищет.
Google воспринимает минус перед словом как оператор отрицания.
(То есть поиск «Иващенко -лимон» ищет только такие страницы про различных Иващенко, которые составлены без упоминания лимонов.)
>>3202778 →
> вменяемый просмотрщик изображений с поддержкой JXL
XnView MP
>>3205312 →
> Что думаете о моей команде для кодирования в SVT-AV1?
Поясните, почему нельзя было вызвать FFmpeg один раз?
ffmpeg -hide_banner -i "sourcefile.mkv" -sn -map_metadata -1 -map_chapters -1 -b:v 0 -c:v libsvtav1 -crf 19 -svtav1-params keyint=1s:film-grain=8:lookahead=120:hierarchical-levels=5:tune=0 -preset 5 -strict -1 -pix_fmt yuv420p10le -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile (svtav1).mkv"
Сразу скажу ещё, что односекундный интервал между ключевыми кадрами представляется маловатым.
Сразу скажу ещё, что без «-strict -1» можно, кажись, обойтись.
>>08639
> зачем и нахуя люди пилят 10 бит видео?
>>3205319 →
> Что такое 10 бит с математическо-программистической точки зрения?
Раз с с математическо-программистической, то сейчас будут заумныя разсужденія.
(Но не такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется.)
Опосля первого появления десятибитности цвѣтовыхъ компонентов в видеофайлах (рѣчь идёт о появлении профиля «High 10» в рекомендациях ITU-T, это было в марте 2005 года) достаточно быстро (в течение нѣсколькихъ лѣтъ) сдѣлалось ясным, что такие видеофайлы лучше подходят (чѣмъ прежние) не только для таких кадров, пикселы которых с сáмого начала и были тридцатибитными, но также и для 24-битных пикселов (TrueColor), состоящих из трёх восьмибитных (а не десятибитных) цвѣтовыхъ компонентов. (Ну, напримѣръ, понимание этого излагается по адресу https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf в таком PDF, который датирован 2010 годом.)
Вот как это устроено:
① Всякое видеокодирование происходит с внесением потерь в кадры.
② Часть алгоритмов видеокодирования устроена таким образом, что их намѣреніемъ является именно внесение потерь в кадры (съ цѣлью сжатия видеоданных). Другая часть алгоритмов (напримѣръ, преобразование кадров или предсказание одних кадров на основе других кадров), напротив, стремится к точности; потери в таких алгоритмах также вносятся, но в силу погрѣшностей, и алгоритмы устроены таким образом, чтобы свести погрѣшности к минимуму.
③ Понятие «погрѣшность невелика» математически означает «погрѣшность сосредоточена в немногих младших разрядах числа» (скажем, в одном-двух младших разрядах).
④ Построение восьмибитных компонентов цвѣта (для реального экранного пиксела на восьмибитном экране) на основе десятибитных компонентов цвѣта (содержащихся в видеофайле) как раз и сводится к отбрасыванию двух младших разрядов каждого компонента — слѣдовательно, таким отбрасыванием устраняются и всѣ погрешности видеокодирования, сосредоточенные (полностью или хотя бы главным образом) в этих разрядах.
⑤ Первоначальное же построение десятибитных компонентов цвѣта (содержащихся в видеофайле) на основе восьмибитных компонентов цвѣта (содержащихся в исходных кадрах видеозаписи) сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов.
⑥ Благодаря двум вышеупомянутым факторам (большей аккуратности видеосжатия и большой первоначальной избыточности видеоданных) происходит вот что: хотя объём видеофайла растёт при перехода к восьмибитности к десятибитности цвѣтовыхъ компонентов, соотношение качества файла и объёма растёт ещё быстрѣе — слѣдовательно, слегка понизив качество кодирования, можно и в прежний объём видеофайла засунуть видео большего качества.
Вот наглядные примѣры двух вышеупомянутых подвидов алгоритмов — вносящих погрѣшности (устранимые десятибитностью) и вносящих намѣренные потери данных:
⓵ Алгоритм преобразования пикселов из RGB въ цвѣторазностное пространство (и обратно) устроен таким образом, что порождает ошибки округления, которые устраняются, если преобразование происходит в большей разрядности (об этом говорит нам первый абзац по адресу https://en.wikipedia.org/wiki/YCbCr#Y'PbPr_to_Y'CbCr в Википедии).
⓶ Намѣреннымъ же внесением ошибок въ цвѣтность (отбрасыванием ¾ цвѣтовой информации в интересах видеосжатия) занимается при этом другой алгоритм, совершающий цвѣтовую субдискретизацию 4:2:0 (см. https://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 в Википедии).
Распробовав рост отношения качества видео к объёму файла, многие авторы видеофайлов вот ужé примѣрно лѣтъ пятнадцать стремятся создавать файлы с тридцатибитными пикселами.
>>08560
> встроенный в 11-е окна плеер не может его показать
Поставь Media Player Classic Home Cinema (по адресу https://github.com/clsid2/mpc-hc/releases возьми).
>>09059
> В ffmpeg ставить только по-старому, значением.
Потому что надо ставить не через «-g значение», а через «-svtav1-params keyint=20s».
Тогда к пониманию смысла подключится SVT-AV1 и будет всё ok.
>>09102
> keyint:10s
Не «:», а «=».
>>09133
> ставишь кодек лайт
Чего только не придумают люди, чтобы не пользоваться готовою встроенностью LAVFilters внутри Media Player Classic Home Cinema.
>>09475
> доказали, что при одинаковом времени кодирования svt-av1 сосёт хуй у aom
У меня прекрасные новости для тебя и других подобных любителей хуесосных метафор.
Но эти новости и кого угодно порадуют.
По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2016#note_1119896397 ясно видно, что скорость работы SVT-AV1 под Windows только что ускорили ШЕСТИКРАТНО: в одном из примѣровъ было 0,178 кадра в секунду (на четвёртом пресете), а стало 1,087.
>>09667
> Когда же декодер добавят в FFmpeg?
Когда закончится срок дѣйствія патента.
Ждём до ≈2032 года.
4 Кб, 562x208Тебя в начальной школе научили слову «чмондель», >>11376, но забыли научить читать табличные данные?
Дочитывать надо.
Никак не отменяет того, что это всего лишь фикс регрессии, чмондель.
>>11361
Нахер столько ждать. Лучше забыть и не вспоминать.
> > Когда же декодер добавят в FFmpeg?
> Когда закончится срок дѣйствія патента.
Нахер столько ждать. Лучше забыть и не вспоминать.
>>11361
Почему числа под люниксам в четыре раза больше. Как ос связана со скоростью кодирования?
>под Windows только что ускорили ШЕСТИКРАТНО
Почему числа под люниксам в четыре раза больше. Как ос связана со скоростью кодирования?
>>11361
Действительно, зачем нужны адские заумия для понтующихся имитацией дореволюционной орфографии, особенно, если они не понимают как работает ДКП и прочие интегральные ортогональные преобразования.
>такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется
>сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов
Действительно, зачем нужны адские заумия для понтующихся имитацией дореволюционной орфографии, особенно, если они не понимают как работает ДКП и прочие интегральные ортогональные преобразования.
>>11385
Что это за картинка, почему на винде так медленно?
Что это за картинка, почему на винде так медленно?
Аноны, вопрос может не совсем по теме, но суть такая.
Есть пейлист на ютубе с видео уроками. Самое важное там это аудио, а видео это по сути набор слайдов.
Хочется пейлист себе сохранить, но так чтобы он не занимал много места.
Как быть в такой ситуации? Слишком низкое качество картинки может не подойти т.к. там текст и потом его не поймёшь.
Есть пейлист на ютубе с видео уроками. Самое важное там это аудио, а видео это по сути набор слайдов.
Хочется пейлист себе сохранить, но так чтобы он не занимал много места.
Как быть в такой ситуации? Слишком низкое качество картинки может не подойти т.к. там текст и потом его не поймёшь.
>>11628
GOP 9999
GOP 9999
>>09903
Для подтверждения что он не наебал с ответами, в старом архиве то же самое. Ты конкурсы в интернете никогда не видел? Без подобного пруфа организатор может изменить ответы по своему желанию.
Для подтверждения что он не наебал с ответами, в старом архиве то же самое. Ты конкурсы в интернете никогда не видел? Без подобного пруфа организатор может изменить ответы по своему желанию.
>>11628
-vf mpdecimate
Если два последовательных кадра дублируются, оно расходует почти 0 битрейта.
>а видео это по сути набор слайдов.
-vf mpdecimate
Если два последовательных кадра дублируются, оно расходует почти 0 битрейта.
Как mkv и ass закодить в mp4? Чтоб субтитры не на видео наложились, а чтобы можно было их переключать/выключать.
>>11703
Никак. Потому что mp4 не нужен, это говноформат без поддержки кодеков и с двойной записью на диск ради быстрого запуска (-movflags +faststart).
Никак. Потому что mp4 не нужен, это говноформат без поддержки кодеков и с двойной записью на диск ради быстрого запуска (-movflags +faststart).
>>11703
Можешь рассказать почему такая задача возникла?
Можешь рассказать почему такая задача возникла?
>>11703
Таккак вконтейнерахMP4 только https://en.wikipedia.org/wiki/MPEG-4_Part_17 поддерживается вкачестве форматасубтитров, топоневоле придётся искать переводчик изASS вэтотформат.
(Яотаком незнаю, напримѣръ.)
Таккак вконтейнерахMP4 только https://en.wikipedia.org/wiki/MPEG-4_Part_17 поддерживается вкачестве форматасубтитров, топоневоле придётся искать переводчик изASS вэтотформат.
(Яотаком незнаю, напримѣръ.)
Сраный новодвижок Двача захавал мои Unicode U+00A0.
Пиздец, невозможно общаться нормально.
Пиздец, невозможно общаться нормально.
>>11703
Мне кажется только рядом с файлом с таким же именем положить, а плеер сам подхватит.
Мне кажется только рядом с файлом с таким же именем положить, а плеер сам подхватит.
Каким поехавшим нужно быть, чтобы муксировать в mp4 а не в mkv?
>>11838
Может быть, остальной софт имеет все те же функции и кодеки, что ffmpeg, и такой же бесплатный?
Может быть, остальной софт имеет все те же функции и кодеки, что ffmpeg, и такой же бесплатный?
Сколько времени примерно займет кодирование полуторачасового фильма в фул хд на впсочке с одним некроядром и 512 мб памяти? Стоит ли это вообще того?
>>11628
Они уже на ютубчики сразу должны быть пережаты как надо, чтобы минимум места занимать. Гугл же не тупые.
Они уже на ютубчики сразу должны быть пережаты как надо, чтобы минимум места занимать. Гугл же не тупые.
>>11873
В принципе да, это тоже может подойти. Скачал длинный видос 30мин+ и не в самом лучшем качестве, но смотрибельный, вышло 31мб.
В принципе да, это тоже может подойти. Скачал длинный видос 30мин+ и не в самом лучшем качестве, но смотрибельный, вышло 31мб.
>>11873
Оно пересжато как надо им, максимально некачественно, с минимальным качеством и размером. Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере
Оно пересжато как надо им, максимально некачественно, с минимальным качеством и размером. Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере
>>12027
И как ты это сделаешь, сверхразум? Как будто этого никто не знает.
>Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере
И как ты это сделаешь, сверхразум? Как будто этого никто не знает.
>>12224
Ютуб транскодирует асиками. Транскод асиками даёт возможность транскодировать очень быстро, но не очень качественно.
Ютуб транскодирует асиками. Транскод асиками даёт возможность транскодировать очень быстро, но не очень качественно.
>>12228
Он имеет ввиду, что исходников от гугла ты не допросишься.
Он имеет ввиду, что исходников от гугла ты не допросишься.
>>12241
Асики от nvidia едва доползли до однопрогодного -preset medium, если говорить о h264. Новейшие асики в видяхах от Intel кодируют AV1 с эффективностью аналогичной x264 -preset veryslow. Для реалтайма может и прорыв, но с кодированием на CPU на медленных настройках не сравниться.
Асики от nvidia едва доползли до однопрогодного -preset medium, если говорить о h264. Новейшие асики в видяхах от Intel кодируют AV1 с эффективностью аналогичной x264 -preset veryslow. Для реалтайма может и прорыв, но с кодированием на CPU на медленных настройках не сравниться.
>>12299
Ты думаешь там кто-то что-то кодирует на асиках потребительских видеокарт?
Ты думаешь там кто-то что-то кодирует на асиках потребительских видеокарт?
Аноны, подскажите, как сделать так, чтобы в конце видео не образовывалось лишних секунд?
Допустим, когда после -r я ставлю 10, то всё нормально
А когда 1 -- остаётся десяток-другой тишины.
Но во втором случае всегда намного меньше веса.
Как собирать шебмы с еденицей фпс и чтобы выходило ровно по времени?
Пример команды:
ffmpeg -r Х -loop 1 -i картинка -i музыка.wav -c:a libopus -b:a 128K -c:v libvpx-vp9 -strict -2 -shortest выход.webm
Допустим, когда после -r я ставлю 10, то всё нормально
А когда 1 -- остаётся десяток-другой тишины.
Но во втором случае всегда намного меньше веса.
Как собирать шебмы с еденицей фпс и чтобы выходило ровно по времени?
Пример команды:
ffmpeg -r Х -loop 1 -i картинка -i музыка.wav -c:a libopus -b:a 128K -c:v libvpx-vp9 -strict -2 -shortest выход.webm
>>12465
По крайне мере стоит попробовать явно указать -t
Если это поможет и если автоматизировать - я бы скрипт на питоне сделал, который получает длительность и вписывает её. Может быть есть способ как-то через командную строку указать, вроде -shortest - я без понятия.
Ещё есть же кодеки поддерживающие переменный fps, думаю через это можно в конце добавить кадр с длительностью нужной.
По крайне мере стоит попробовать явно указать -t
Если это поможет и если автоматизировать - я бы скрипт на питоне сделал, который получает длительность и вписывает её. Может быть есть способ как-то через командную строку указать, вроде -shortest - я без понятия.
Ещё есть же кодеки поддерживающие переменный fps, думаю через это можно в конце добавить кадр с длительностью нужной.
>>12465
Это баг даже не -r вроде, а самого ffmpeg когда пытаешься залупить картинку. Хотя мб ты нашел причину, просто ставь -t под длительность музыки.
Это баг даже не -r вроде, а самого ffmpeg когда пытаешься залупить картинку. Хотя мб ты нашел причину, просто ставь -t под длительность музыки.
>>12505
Зачем? Я с тем же успехом могу тупо один фрейм с картинкой закодировать. Что так что этак прокрутка идёт по пизде.
> -g 9999
Зачем? Я с тем же успехом могу тупо один фрейм с картинкой закодировать. Что так что этак прокрутка идёт по пизде.
Поясните за реалтайм на svtav1. Он же не умеет кодировать ни в rgb, ни в 4:4:4, нахуя он нужен? Проще же реально использовать всё тот же x264, пусть и с чуть большим битрейтом, зато без мыла.
>>12563
Он все еще в активной разработке.
Используй.
> Поясните за реалтайм на svtav1. Он же не умеет кодировать ни в rgb, ни в 4:4:4, нахуя он нужен?
Он все еще в активной разработке.
> Проще же реально использовать всё тот же x264, пусть и с чуть большим битрейтом, зато без мыла.
Используй.
>>12564
Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.
>Он все еще в активной разработке.
Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.
>>12622
Вопрос снят, я жопочтец.
>tduration(input/output)
> When used as an input option (before-i),
> limit thedurationof data read from the input file.
Вопрос снят, я жопочтец.
>>12568
Ядро Linux пилят 20+ лет, перешагнуло 6.0.0, все еще в активной разработке. Дальше что?
> Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.
Ядро Linux пилят 20+ лет, перешагнуло 6.0.0, все еще в активной разработке. Дальше что?
>>12636
Хомо сапиенс эволюционировал уже как 50 тысяч лет, изобрел спермерочку и всё ещё активно эволюционирует. Дальше что?
Хомо сапиенс эволюционировал уже как 50 тысяч лет, изобрел спермерочку и всё ещё активно эволюционирует. Дальше что?
А ваш чудо ffmpeg может прям напрямую из видеофайла сразу вырезать нужный кусок без ёбли и кучи команд? Если да, тогда подумаю о переходе, смотрю много контента и много сцен бывает, которые хочется вырезать и отправить подружке
>>12622
В аутпут лучше в параметры кодироваания видео после основных.
В аутпут лучше в параметры кодироваания видео после основных.
>>12756
avidemux резка с ключевого кадра.
avidemux резка с ключевого кадра.
>>12855
В правом нижнем углу формы ввода написано для каждой доски.
В правом нижнем углу формы ввода написано для каждой доски.
>>12505
Не нужна субдискретизация при такой частоте кадров.
Это экономия на спичках.
> -pix_fmt yuv420p
Не нужна субдискретизация при такой частоте кадров.
Это экономия на спичках.
>>12899
Дело скорее в совместимости, охват утюгов, которые декодируют 420 больше.
Дело скорее в совместимости, охват утюгов, которые декодируют 420 больше.
13 Кб, 617x352Пачаны, как в ффмпеге задать очередь? у меня есть список команд, но по одной заебался вводить. Спасибо.
>>12921
и ещё ест трабла, первые 1-2 минуты видоса очень пиксельные, потом всё идеально, как фиксить? без поднятия битрейта желательно, конверчу на долгое хранение
и ещё ест трабла, первые 1-2 минуты видоса очень пиксельные, потом всё идеально, как фиксить? без поднятия битрейта желательно, конверчу на долгое хранение
>>12921
Там одинаковые настройки и только названия разные?
Батник, не? Или скрипт твоей ос, или просто на питоне через subprocess?
Там одинаковые настройки и только названия разные?
Батник, не? Или скрипт твоей ос, или просто на питоне через subprocess?
>>12932
не там есть траблы с сабами и аудио, надо вручную выбирать дорожки, это заёбно но я составляю такие списки заранее и потом по одной серии конверчу, я хз даже как через батник, типа каждую серию в отдельный тхт и как то потоком поставить?
не там есть траблы с сабами и аудио, надо вручную выбирать дорожки, это заёбно но я составляю такие списки заранее и потом по одной серии конверчу, я хз даже как через батник, типа каждую серию в отдельный тхт и как то потоком поставить?
>>12922
Не кодировать в CBR. Лучше поставь двухпроходный VBR.
Не кодировать в CBR. Лучше поставь двухпроходный VBR.
Из 2мб видео эта хуйня выгнала мне 13мб гифку. Ебать. Как ето возможно вообще, я гиф делал наоборот чтобы меньше места занимало.
>>12942
Ты идиот? Гифки это древний формат с древними принципами сжатия. И вообще гифкам место на свалке истории. Жаль им до сих пор не придумали адекватной замены.
Но сравнивать древний формат из восьмидесятых с современными видеокодеками это конечно шиза.
Ты идиот? Гифки это древний формат с древними принципами сжатия. И вообще гифкам место на свалке истории. Жаль им до сих пор не придумали адекватной замены.
Но сравнивать древний формат из восьмидесятых с современными видеокодеками это конечно шиза.
>>12921
echo "команда 1" && echo "команда 2"
echo "команда 1" && echo "команда 2"
>>12942
Потому что гиф это ряд картинок jpg буквально. допустим jpg весит 500кб в ней 60 кадров всего. Вот и умножай сколько получится - 30мб
Потому что гиф это ряд картинок jpg буквально. допустим jpg весит 500кб в ней 60 кадров всего. Вот и умножай сколько получится - 30мб
>>13013
До меня правда только что начало доходить, что в исходнике кадры пожаты 264-м, в то время как гиф ничего не жмет сам по себе, только если скажешь ффмпегу жать твою гифку с доп. параметрами.
Обязательно меня идиотом называть, если мне раз в сто лет пришло сделать такую штуку и я сходу не разобрался, что к чему? Почему жизнь ко мне так несправедлива и жестока.
До меня правда только что начало доходить, что в исходнике кадры пожаты 264-м, в то время как гиф ничего не жмет сам по себе, только если скажешь ффмпегу жать твою гифку с доп. параметрами.
Обязательно меня идиотом называть, если мне раз в сто лет пришло сделать такую штуку и я сходу не разобрался, что к чему? Почему жизнь ко мне так несправедлива и жестока.
>>13019
Тебе не нужны гифки для сжатия. Методы компрессии формата GIF устарели, и не могут быть использованы для транскодирования видео в сколько нибудь приемлемом качестве.
Тебе не нужны гифки для сжатия. Методы компрессии формата GIF устарели, и не могут быть использованы для транскодирования видео в сколько нибудь приемлемом качестве.
>>13013
Ну у джипега перед гифкой есть преимущество: ДКП. А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.
Ну у джипега перед гифкой есть преимущество: ДКП. А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.
>>13023
Потому что GIF внезапно loseless (LZW). В отличие от.
> А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.
Потому что GIF внезапно loseless (LZW). В отличие от.
76 Кб, 816x474>>12935
Совсем вручную? Ну, если там разумное количество файлов, то просто скопировать строчку нужное число раз и вставлять номера дорожки. Если безумное, то ты всё-равно на ручной просмотр времени много потратишь.
Но даже без скриптов ты можешь просто список файлов сделать с номерами, и через замену заменить разделители на остальные параметры.
Какой txt?
Просто кучу команд пишешь и запускаешь, оно их само по очереди все сделает, ещё можешь загуглить что такое shift и %1 в батниках, ещё быстрее сделаешь. Если хочешь вместе, то нужно либо команду для cmd запуска в отдельном потоке искать, либо через питон. И ещё всё зависнет, так как после десяти одновременных экземпляров даже мышка будет плохо двигаться.
>надо вручную выбирать дорожки
Совсем вручную? Ну, если там разумное количество файлов, то просто скопировать строчку нужное число раз и вставлять номера дорожки. Если безумное, то ты всё-равно на ручной просмотр времени много потратишь.
Но даже без скриптов ты можешь просто список файлов сделать с номерами, и через замену заменить разделители на остальные параметры.
>типа каждую серию в отдельный тхт и как то потоком поставить?
Какой txt?
Просто кучу команд пишешь и запускаешь, оно их само по очереди все сделает, ещё можешь загуглить что такое shift и %1 в батниках, ещё быстрее сделаешь. Если хочешь вместе, то нужно либо команду для cmd запуска в отдельном потоке искать, либо через питон. И ещё всё зависнет, так как после десяти одновременных экземпляров даже мышка будет плохо двигаться.
>>12942
Пробуй делать APNG. Многие забывают про этот кошерный формат, в то время как слово гифка стало маркером быдла, как и эмэрзе.
Пробуй делать APNG. Многие забывают про этот кошерный формат, в то время как слово гифка стало маркером быдла, как и эмэрзе.
>>13419
Те же методы сжатия что и у GIF. Единственное преимущество перед GIF — поддержка 24-битного цвета.
Не знаю чего там напридумали инженеры из гугла, но WEBM из VP8 будет весить меньше, чем WEBP. Экономия от пережатия GIF в lossy WEBP составляет какие-то жалкие 25-50%.
А если пережать в H264/VP9, то полученный файл будет в разы меньше гифки. Но если открыть этот файл в браузере, то там будет видна пауза между повторами.
> APNG
Те же методы сжатия что и у GIF. Единственное преимущество перед GIF — поддержка 24-битного цвета.
> WEBP
Не знаю чего там напридумали инженеры из гугла, но WEBM из VP8 будет весить меньше, чем WEBP. Экономия от пережатия GIF в lossy WEBP составляет какие-то жалкие 25-50%.
А если пережать в H264/VP9, то полученный файл будет в разы меньше гифки. Но если открыть этот файл в браузере, то там будет видна пауза между повторами.
>>13426
А то что та же анимация занимает в 10 раз меньше места, если там схематичное что-то это не преимущество?
Это всё ещё не исключает того, что webp намного юзабельнее чем gif, просто в десятки раз.
Давай я сделаю отрывок на 2 секунды в 1280х720х60 на 2 мб, а ты покажешь как ты делаешь гифку 1280х720х60 на 2 мб. Таких гифок просто нет, так как там по 50 мб будет, и даже если закодировать в 16 цветов, что выйдет громадными артефактами - это будет всё-равно больше 10 мб весить. А vp8 запросто и 10 секунд "сложного" видео покажет, так что будет понятно что происходит на экране. Фигню ты сказал про экономию в 25-50%.
Вроде бы какой-то флаг кодирования есть в одном из форматов...
>Единственное преимущество перед GIF — поддержка 24-битного цвета.
А то что та же анимация занимает в 10 раз меньше места, если там схематичное что-то это не преимущество?
>но WEBM из VP8 будет весить меньше, чем WEBP.
Это всё ещё не исключает того, что webp намного юзабельнее чем gif, просто в десятки раз.
>Экономия от пережатия GIF в lossy WEBP составляет какие-то жалкие 25-50%.
Давай я сделаю отрывок на 2 секунды в 1280х720х60 на 2 мб, а ты покажешь как ты делаешь гифку 1280х720х60 на 2 мб. Таких гифок просто нет, так как там по 50 мб будет, и даже если закодировать в 16 цветов, что выйдет громадными артефактами - это будет всё-равно больше 10 мб весить. А vp8 запросто и 10 секунд "сложного" видео покажет, так что будет понятно что происходит на экране. Фигню ты сказал про экономию в 25-50%.
> Но если открыть этот файл в браузере, то там будет видна пауза между повторами.
Вроде бы какой-то флаг кодирования есть в одном из форматов...
785 Кб, 250x300>>13492
Запости, хочу глянуть.
> Это всё ещё не исключает того, что webp намного юзабельнее чем gif, просто в десятки раз
Запости, хочу глянуть.
>>13492
VP8 да, Анимированный WEBP не факт что вообще влезет в твои лимиты. Опять же, ты даже не пробовал сжимать.
> А vp8 запросто и 10 секунд "сложного" видео покажет, так что будет понятно что происходит на экране. Фигню ты сказал про экономию в 25-50%.
VP8 да, Анимированный WEBP не факт что вообще влезет в твои лимиты. Опять же, ты даже не пробовал сжимать.
36 Кб, 724x724>>13502
А что с ними ещё делать? Коллекционировать и рассматривать долгими зимними вечерами? И эти форматы постятся не только на двачах, потому странно хранить изображения в форматах, которые используют 3.5 софтовых калеки.
> Хотя если тебе надо постить на двачах
А что с ними ещё делать? Коллекционировать и рассматривать долгими зимними вечерами? И эти форматы постятся не только на двачах, потому странно хранить изображения в форматах, которые используют 3.5 софтовых калеки.
Разве поддержку webp не сделали с новым движком?
упд. Мда кал нельзя запостить, еще и поддержку mp3 пидорнули.
упд. Мда кал нельзя запостить, еще и поддержку mp3 пидорнули.
>>13514
Зато новый движок не падает постоянно с 502 Плохие Ворота. Хотя нет, подождите...
Зато новый движок не падает постоянно с 502 Плохие Ворота. Хотя нет, подождите...
773 Кб, 1280x720Вопрос пользователям ff2mpv, это нормально что для запуска данного 30 секундного видео с ютуба в mpv требуется около 5 секунд? Так и должно быть или я что-то не так сделал, чому так долго?
https://www.youtube.com/watch?v=dap5lEuS5uM
https://www.youtube.com/watch?v=dap5lEuS5uM
>>13552
Ну так пока yt-dlp одуплится, пока mpv всё это прожуёт, секунд 5 и пройдёт. Сам попробуй введи команды в консольку и посмотри сколько по времени весь процесс займёт.
На линуксе кстати быстрее всё происходит.
Ну так пока yt-dlp одуплится, пока mpv всё это прожуёт, секунд 5 и пройдёт. Сам попробуй введи команды в консольку и посмотри сколько по времени весь процесс займёт.
На линуксе кстати быстрее всё происходит.
Зачем нужна WebM, если это кастрированная Matroska? Google явно не по приколу её разработал, в чём тогда смысл?
>>13553
Так это же ютубовское ограничение скорее, а не сишки или ещё чего.
>>13619
Во-первых, немного полегче контейнер, во-вторых предположу что специально.
Написать что бравзер поддерживает webm - норм. А написать браузер поддерживает mkv, но только видеодорожки форматов h264, vp8, ... и аудиодорожки форматов ... - это намного недружелюбнее для пользователей.
Спроси у обывателя какие форматы поддерживает его видео плеер - он скажет что mp4, avi и что там ещё бывает. А при упоминании avc или h264 скажет что первый раз слышит.
Так это же ютубовское ограничение скорее, а не сишки или ещё чего.
>>13619
Во-первых, немного полегче контейнер, во-вторых предположу что специально.
Написать что бравзер поддерживает webm - норм. А написать браузер поддерживает mkv, но только видеодорожки форматов h264, vp8, ... и аудиодорожки форматов ... - это намного недружелюбнее для пользователей.
Спроси у обывателя какие форматы поддерживает его видео плеер - он скажет что mp4, avi и что там ещё бывает. А при упоминании avc или h264 скажет что первый раз слышит.
>>13651
Что специально? Ну да, я и говорю, что не случайно, только зачем делать матрёшку, которая умеет меньше оригинала?
Что специально? Ну да, я и говорю, что не случайно, только зачем делать матрёшку, которая умеет меньше оригинала?
Есть два вьювера - Xnview и Honeyview. В них, что с фильтрами, что без фильтров, картинка отличается - она как-будто поделена на огромные области, которые стыкуются между собой и как бы дорисовывают детали, либо съедают их. Деформируют картинку на пол процента, сохраняя суть, но микро-формы по пикселям отличаются. Почему так? Где картинка правильнее?
>>13725
С масштабом 100% уже выглядят почти одинаково. Но всё-равно отличаются - по краям смещение кадра на пару пикселей, как будто обрезали. И сама область с картинкой на чёрном фоне сдвинута на пару пикселей.
С масштабом 100% уже выглядят почти одинаково. Но всё-равно отличаются - по краям смещение кадра на пару пикселей, как будто обрезали. И сама область с картинкой на чёрном фоне сдвинута на пару пикселей.
>>13552
Potplayer ytdlp открывает сразу за 1-2 сек, но в общем всё вместе пока ytdlp догрузит тоже 5 сек.
Potplayer ytdlp открывает сразу за 1-2 сек, но в общем всё вместе пока ytdlp догрузит тоже 5 сек.
3 Кб, 433x51>>13760
Вряд ли там галочка есть, но вроде бы там была строчка дополнительных параметров для ffmpeg, вот туда попробуй что-то вроде этого дописать.
https://ffmpeg.org/ffmpeg-filters.html#toc-dynaudnorm
Ещё фильтр loudnorm поищи.
Вряд ли там галочка есть, но вроде бы там была строчка дополнительных параметров для ffmpeg, вот туда попробуй что-то вроде этого дописать.
https://ffmpeg.org/ffmpeg-filters.html#toc-dynaudnorm
Ещё фильтр loudnorm поищи.
>>13871
Пробуй пока не получится, строка ретарда вроде как напрямую скармливается ффмпегу.
Пробуй пока не получится, строка ретарда вроде как напрямую скармливается ффмпегу.
>>13871
Хм, может внутренний ffmpeg нужно поменять на более новый.
Там же при сборке можно отключить не нужное, может быть и этот фильтр отключили...
Не знаю что посоветовать, кроме как сделать через чистый ffmpeg, или попробовать внутренний поменять на новый отдельно скаченный.
>>13892
Нет, ему же прямо написало, что оно поняло название фильтра, но фильтра такого не обнаружило.
Хм, может внутренний ffmpeg нужно поменять на более новый.
Там же при сборке можно отключить не нужное, может быть и этот фильтр отключили...
Не знаю что посоветовать, кроме как сделать через чистый ffmpeg, или попробовать внутренний поменять на новый отдельно скаченный.
>>13892
Нет, ему же прямо написало, что оно поняло название фильтра, но фильтра такого не обнаружило.
>>13901
а как?
нихуя не получается, ничего не понимаю...
> Хм, может внутренний ffmpeg нужно поменять на более новый.
а как?
> сделать через чистый ffmpeg, или попробовать внутренний поменять на новый отдельно скаченный
нихуя не получается, ничего не понимаю...
>>13725
Пиши подробности про XnView.
Он у тебя классический или XnView MP?
>>13426
Бредятина!
Во-первых, DEFLATE — это не LZW.
Во-вторых, используются предикторы.
Также ерунда: во-первых, не единственное, а во-вторых, PNG поддерживает и 48-битный цвѣтъ.
Пиши подробности про XnView.
Он у тебя классический или XnView MP?
>>13426
> APNG
> Те же методы сжатия что и у GIF.
Бредятина!
Во-первых, DEFLATE — это не LZW.
Во-вторых, используются предикторы.
> Единственное преимущество перед GIF — поддержка 24-битного цвета.
Также ерунда: во-первых, не единственное, а во-вторых, PNG поддерживает и 48-битный цвѣтъ.
>>14053
Да, он.
Да я свою претензию уже написал. Ещё могу сказать, что он, имхо, запускается дольше, и если нажать не ту клавишу, то вместо выхода из программы откроешь интерфейс эдакого проводника вместе с картинкой.
>XnView MP
Да, он.
>Пиши подробности про XnView.
Да я свою претензию уже написал. Ещё могу сказать, что он, имхо, запускается дольше, и если нажать не ту клавишу, то вместо выхода из программы откроешь интерфейс эдакого проводника вместе с картинкой.
>>14053
Да похуй. Lossless сжатие это последнее что меня интересует.
Которые предсказывают лишь 1 пиксел от 3-x или 4-x ближайших соседних пикселей, в противовес тому же VP8 где предсказывается макроблок из крайних пикселей соседних макроблоков. И это я ещё не говорю про AV1 где эти блоки могут быть переменного размера и к тому же могут иметь неквадратную форму.
> Во-первых, DEFLATE — это не LZW.
Да похуй. Lossless сжатие это последнее что меня интересует.
> Во-вторых, используются предикторы.
Которые предсказывают лишь 1 пиксел от 3-x или 4-x ближайших соседних пикселей, в противовес тому же VP8 где предсказывается макроблок из крайних пикселей соседних макроблоков. И это я ещё не говорю про AV1 где эти блоки могут быть переменного размера и к тому же могут иметь неквадратную форму.
Как быстро скачивать ютуб лайв стримы, которую после того, как он закончится, будет недоступен. ytdl+ffmpeg очень долго качает, потому что качает m3u8 и постоянно парсит hls куски, в общем долго кушает, еще и одним потоком похоже. пробовал 4kdownlaoder, но он как будто вообще не качает.
>>14991
Он еще и качает с конца как бы, вот что хуже всего. Сейчас был стрим на 1 час и 40 мин, скачал 50 мин, и получается первых 50 минут нет.
Он еще и качает с конца как бы, вот что хуже всего. Сейчас был стрим на 1 час и 40 мин, скачал 50 мин, и получается первых 50 минут нет.
>>14991
Записать с помощью mpv.
stream-record, или dump-cache команды.
https://mpv.io/manual/master/#options-stream-record
https://mpv.io/manual/master/#command-interface-dump-cache
Записать с помощью mpv.
stream-record, или dump-cache команды.
https://mpv.io/manual/master/#options-stream-record
https://mpv.io/manual/master/#command-interface-dump-cache
>>05384 (OP)
Какой из гуев сегодня жив?
Немного полистал поиск на гитхабе, очень много тех кто уже по 2-3 года не обновлялся
Какой из гуев сегодня жив?
Немного полистал поиск на гитхабе, очень много тех кто уже по 2-3 года не обновлялся
>>15519
handbrake
handbrake
1,5 Мб, mp4,850x576, 0:12
Сделал вещицу вот.
Принимает на вход текстовый файл и картинку, результат видите.
Изначально увидел подобное в тиктоке/телеге, на каналах, где читают с реддита или всякие новости. Но там было так, что текст сразу весь на экране, я решил сделать, чтоб "типа" со скоростью чтения он проявлялся. В итоге год назад сделал, но нигде так и не использовал, сейчас вот вспомнил. Вроде, вполне неплохо, особенно если вместо стандартного синтезатора использовать качественный.
Можно генерить сотни, тысячи таких текстовых видосов батчем.
Вопрос. Где это можно использовать?
Думал сделать канал в телеге или тиктоке, чтоб туда автоматически загружался каждый день видос, допустим, с топ новостью для из какого-то источника.. На этом идеи акончились.
Подкиншь мыслишек, анон?
Принимает на вход текстовый файл и картинку, результат видите.
Изначально увидел подобное в тиктоке/телеге, на каналах, где читают с реддита или всякие новости. Но там было так, что текст сразу весь на экране, я решил сделать, чтоб "типа" со скоростью чтения он проявлялся. В итоге год назад сделал, но нигде так и не использовал, сейчас вот вспомнил. Вроде, вполне неплохо, особенно если вместо стандартного синтезатора использовать качественный.
Можно генерить сотни, тысячи таких текстовых видосов батчем.
Вопрос. Где это можно использовать?
Думал сделать канал в телеге или тиктоке, чтоб туда автоматически загружался каждый день видос, допустим, с топ новостью для из какого-то источника.. На этом идеи акончились.
Подкиншь мыслишек, анон?
>>15898
Не понравилось?
Не понравилось?
134 Кб, 1320x702Делаю аналог lofi hip-hop радио.
В бесконечном цикле скачиваю следующую песню с ютуба, стримлю ее в буфер, потом из буфера стримлю уже на ютуб.
Чуть-чуть идет, но потом прерывается..
Не могу понять, что за "Broken pipe".. Ничего не смог нагуглить.
Менял по разному размер буфера и битрейт выходного потока, но это без изменений.
Кикие мысли, анончик?
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
size= 4kB time=00:00:00.16 bitrate= 195.8kbits/s speed=1.71e+03x
video:0kB audio:3kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 30.555555% Conversion failed! ERROR: [Errno 32] Broken pipe Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='utf-8'> BrokenPipeError: [Errno 32] Broken pipe
В бесконечном цикле скачиваю следующую песню с ютуба, стримлю ее в буфер, потом из буфера стримлю уже на ютуб.
Чуть-чуть идет, но потом прерывается..
Не могу понять, что за "Broken pipe".. Ничего не смог нагуглить.
Менял по разному размер буфера и битрейт выходного потока, но это без изменений.
Кикие мысли, анончик?
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
size= 4kB time=00:00:00.16 bitrate= 195.8kbits/s speed=1.71e+03x
video:0kB audio:3kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 30.555555% Conversion failed! ERROR: [Errno 32] Broken pipe Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='utf-8'> BrokenPipeError: [Errno 32] Broken pipe
>>16249
Пайп в принципе через жопу работает как-то. Пытался последний раз, а он не в какую.
Пайп в принципе через жопу работает как-то. Пытался последний раз, а он не в какую.
Подскажите пожалуйста
есть видео 1280x720.mp4 сделал гифку 300x300, в гифке черные полосы по бокам как покифксить?
есть видео 1280x720.mp4 сделал гифку 300x300, в гифке черные полосы по бокам как покифксить?
>>17161
откати апдейт
откати апдейт
>>17115
понял, спасибо, учусь по статье https://video.stackexchange.com/questions/4563/how-can-i-crop-a-video-with-ffmpeg
может подсказать как узнать координаты картинки чтобы знать какую именно область в видео мне нужно вырезать
понял, спасибо, учусь по статье https://video.stackexchange.com/questions/4563/how-can-i-crop-a-video-with-ffmpeg
может подсказать как узнать координаты картинки чтобы знать какую именно область в видео мне нужно вырезать
297 Кб, 959x530>>17752
Делай кроп хандбраке, там есть удобное превью с возможностью указать кроп on-the-fly. Не еби себе мозги с ффмпежей, он не создан для динамического редактирования видео.
> может подсказать как узнать координаты картинки чтобы знать какую именно область в видео мне нужно вырезать
Делай кроп хандбраке, там есть удобное превью с возможностью указать кроп on-the-fly. Не еби себе мозги с ффмпежей, он не создан для динамического редактирования видео.
>>17752
Сделай скриншот кадра с хорошо различимой границей между видео и чёрной полосой.
Открывай в любом графическом редакторе (хоть в фотошопе, хоть в гимпе, не важно, главное в пеинте не открывай). Приближаешь на 400+ %. Берешь инструмент линейка, ставишь горизонтально на границах с контентом и полосой, после чего берёшь горизонтальные направляющие и ставишь направляющие на линейку. У тебя должно получиться 2 горизонтальные направляющие.
Снова берёшь линейку и меряешь пиксели от верхнего угла до верхней направляющей. Это и будет твой «x». Потом меряешь линейкой расстояние от верхней направляющей до нижней направляющей. Это будет твой «h».
Сделай скриншот кадра с хорошо различимой границей между видео и чёрной полосой.
Открывай в любом графическом редакторе (хоть в фотошопе, хоть в гимпе, не важно, главное в пеинте не открывай). Приближаешь на 400+ %. Берешь инструмент линейка, ставишь горизонтально на границах с контентом и полосой, после чего берёшь горизонтальные направляющие и ставишь направляющие на линейку. У тебя должно получиться 2 горизонтальные направляющие.
Снова берёшь линейку и меряешь пиксели от верхнего угла до верхней направляющей. Это и будет твой «x». Потом меряешь линейкой расстояние от верхней направляющей до нижней направляющей. Это будет твой «h».
>>17844
Извините, опечатался. Х это всё таки для обрезки по горизонтали, а не по вертикали. Так что это будет не X а Y.
> Это и будет твой «y»
Извините, опечатался. Х это всё таки для обрезки по горизонтали, а не по вертикали. Так что это будет не X а Y.
>>17752
ffmpeg -hide_banner -ss X -i in.mkv -frames:v 1 -vf cropdetect -f null -
, где X - время кадра с черными полосами.
Ищешь в выводе строчку где написано crop=..., копируешь это, вставляешь в фильтры, Профит.
ffmpeg -hide_banner -ss X -i in.mkv -frames:v 1 -vf cropdetect -f null -
, где X - время кадра с черными полосами.
Ищешь в выводе строчку где написано crop=..., копируешь это, вставляешь в фильтры, Профит.
>>17752
Я в paint.net на скриншоте смотрю координаты для кропа.
Я в paint.net на скриншоте смотрю координаты для кропа.
К вопросу, где этот ваш av1 используется: пикабу на него переходит.
Например: https://pikabu.ru/story/passazhirka_kinula_taksista_na_1700r_9580107
Наверно, в него кодируются ролики только из самых популярных постов, как и в случае в ютюбом.
Например: https://pikabu.ru/story/passazhirka_kinula_taksista_na_1700r_9580107
Наверно, в него кодируются ролики только из самых популярных постов, как и в случае в ютюбом.
Мне чел в арматреде сказал что у него ав1-ств кодирует быстрее чем вп9. Ну оно, конечно, возможно, если ав1 поставить пресет 10, но всё же, при равном времени кодирования, у кого будет качество лучше?
>>19060
Открой в mpv. Алсо, там даже в названии файла av1. Сохранил – MediaInfo показывает av1. Как ты его в vp9-то умудрился открыть?
Открой в mpv. Алсо, там даже в названии файла av1. Сохранил – MediaInfo показывает av1. Как ты его в vp9-то умудрился открыть?
>>19115
У меня Polaris. Он не то что av1, даже vp9 не декодирует. И да, при чём здесь это?
У меня Polaris. Он не то что av1, даже vp9 не декодирует. И да, при чём здесь это?
>>18961
У меня то же самое даже на пресете 5, на обычном ноутбучном процессоре. А на пресете 7 в разы быстрее libvpx-vp9, при качестве немного выше.
Вообще есть же ещё svt-vp9 какой-то...
У меня то же самое даже на пресете 5, на обычном ноутбучном процессоре. А на пресете 7 в разы быстрее libvpx-vp9, при качестве немного выше.
Вообще есть же ещё svt-vp9 какой-то...
>>19452
:st
if %1=="" exit
ffmpeg -i %1 -c:v libx264 -crf 30 -c:a libvorbis -b:a 64k "%~dpn1_h264-27_ab-64.mp4"
::echo "+++"
shift
goto st
Мышкой выделяешь файлы и на батник перетаскиваешь, все строчки кроме длинной чтобы открывать несколько файлов. Но это не сработает, если у тебя несколько аудиодорожек или ещё что-то сложное в видео.
:st
if %1=="" exit
ffmpeg -i %1 -c:v libx264 -crf 30 -c:a libvorbis -b:a 64k "%~dpn1_h264-27_ab-64.mp4"
::echo "+++"
shift
goto st
Мышкой выделяешь файлы и на батник перетаскиваешь, все строчки кроме длинной чтобы открывать несколько файлов. Но это не сработает, если у тебя несколько аудиодорожек или ещё что-то сложное в видео.
280 Кб, 3000x1887>>19507
Большое спасибо.
Кстати твоя команда даже лучше дефолтной, аж в 2 раза файл меньше весит на выходе.
Как научиться писать такие батники?
Большое спасибо.
Кстати твоя команда даже лучше дефолтной, аж в 2 раза файл меньше весит на выходе.
Как научиться писать такие батники?
20 Кб, 787x156Аноны, подскажите.
Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере MKV, внутри - H.264. Недокачаны потому, что в торренте - mkv с фильмом и "левый" txt-файл, и вот на этот последний кусок торрента нет сидов. Внутри самого торрента эти два файла расположены именно в таком порядке, поэтому у видеофайла не докачаны последние пара мегабайт в конце, а не первые пара мегабайт в начале, где заголовки.
Иными словами, видеофайл - с поврежденным последним 0.1%.
Вот такие видеофайлы почему-то ломают софтверный плеер MPC-HC. Фильм включается нормально, но при любой попытке скипнуть на рандомный момент или даже сменить аудиодорожку во время воспроизведения MPC-HC целиком зависает и начинает с максимальной скоростью ебать жесткий диск, на котором лежит файл.
При этом другим софтом, например, Avidemux (обертка над кодеками для линейного редактирования и перекодирования) файл открывается нормально. Как и с любым другим mkv, фильм открывается медленно (пару минут происходят операции типа Matroska clusters, Matroska images, Checking if timestamps are valid), но после завершения этих операций открытия можно скакать в любое место фильма без проблем и делать с видеорядом что угодно.
Если с помощью mkvtoolnix "пересобрать" этот видеофайл, без перекодирования, оставив все оригинальные дорожки и просто указав промежуток 00:00:00-[за несколько секунд до конца фильма], то фильм пересоберется успешно, без нескольких последних секунд, и вот этот пересобранный видеофайл уже будет нормально воспроизводиться MPC-HC, хотя в нем ровно тот же самый видеопоток, что и в оригинальном файле с поврежденным хвостом.
Mkvtoolnix при такой пересборке пишет в лог следующую ошибку, но пересобирает успешно:
Error in the Matroska file structure at position 12461336755. Resyncing to the next level 1 element.
The last timestamp processed before the error was encountered was 01:54:20.896000000.
Resync failed: no valid Matroska level 1 element found.
Что же касается MPC-HC, то почему-то он зависает и начинает ебать жесткий диск только с теми файлами, у которых не докачаны последние несколько мегабайт в хвосте. А файлы, в которых не докачано что-то в середине, воспроизводятся абсолютно нормально. Само собой, с глюком на поврежденных местах, но по файлу можно спокойно перемещаться, и все остальные фрагменты воспроизводятся без проблем.
Что такого особенного находится в хвосте видеофайла mkv, что MPC-HC моментально детектит какую-то проблему с файлом и сходит с ума?
Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере MKV, внутри - H.264. Недокачаны потому, что в торренте - mkv с фильмом и "левый" txt-файл, и вот на этот последний кусок торрента нет сидов. Внутри самого торрента эти два файла расположены именно в таком порядке, поэтому у видеофайла не докачаны последние пара мегабайт в конце, а не первые пара мегабайт в начале, где заголовки.
Иными словами, видеофайл - с поврежденным последним 0.1%.
Вот такие видеофайлы почему-то ломают софтверный плеер MPC-HC. Фильм включается нормально, но при любой попытке скипнуть на рандомный момент или даже сменить аудиодорожку во время воспроизведения MPC-HC целиком зависает и начинает с максимальной скоростью ебать жесткий диск, на котором лежит файл.
При этом другим софтом, например, Avidemux (обертка над кодеками для линейного редактирования и перекодирования) файл открывается нормально. Как и с любым другим mkv, фильм открывается медленно (пару минут происходят операции типа Matroska clusters, Matroska images, Checking if timestamps are valid), но после завершения этих операций открытия можно скакать в любое место фильма без проблем и делать с видеорядом что угодно.
Если с помощью mkvtoolnix "пересобрать" этот видеофайл, без перекодирования, оставив все оригинальные дорожки и просто указав промежуток 00:00:00-[за несколько секунд до конца фильма], то фильм пересоберется успешно, без нескольких последних секунд, и вот этот пересобранный видеофайл уже будет нормально воспроизводиться MPC-HC, хотя в нем ровно тот же самый видеопоток, что и в оригинальном файле с поврежденным хвостом.
Mkvtoolnix при такой пересборке пишет в лог следующую ошибку, но пересобирает успешно:
Error in the Matroska file structure at position 12461336755. Resyncing to the next level 1 element.
The last timestamp processed before the error was encountered was 01:54:20.896000000.
Resync failed: no valid Matroska level 1 element found.
Что же касается MPC-HC, то почему-то он зависает и начинает ебать жесткий диск только с теми файлами, у которых не докачаны последние несколько мегабайт в хвосте. А файлы, в которых не докачано что-то в середине, воспроизводятся абсолютно нормально. Само собой, с глюком на поврежденных местах, но по файлу можно спокойно перемещаться, и все остальные фрагменты воспроизводятся без проблем.
Что такого особенного находится в хвосте видеофайла mkv, что MPC-HC моментально детектит какую-то проблему с файлом и сходит с ума?
20 Кб, 787x156Аноны, подскажите.
Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере MKV, внутри - H.264. Недокачаны потому, что в торренте - mkv с фильмом и "левый" txt-файл, и вот на этот последний кусок торрента нет сидов. Внутри самого торрента эти два файла расположены именно в таком порядке, поэтому у видеофайла не докачаны последние пара мегабайт в конце, а не первые пара мегабайт в начале, где заголовки.
Иными словами, видеофайл - с поврежденным последним 0.1%.
Вот такие видеофайлы почему-то ломают софтверный плеер MPC-HC. Фильм включается нормально, но при любой попытке скипнуть на рандомный момент или даже сменить аудиодорожку во время воспроизведения MPC-HC целиком зависает и начинает с максимальной скоростью ебать жесткий диск, на котором лежит файл.
При этом другим софтом, например, Avidemux (обертка над кодеками для линейного редактирования и перекодирования) файл открывается нормально. Как и с любым другим mkv, фильм открывается медленно (пару минут происходят операции типа Matroska clusters, Matroska images, Checking if timestamps are valid), но после завершения этих операций открытия можно скакать в любое место фильма без проблем и делать с видеорядом что угодно.
Если с помощью mkvtoolnix "пересобрать" этот видеофайл, без перекодирования, оставив все оригинальные дорожки и просто указав промежуток 00:00:00-[за несколько секунд до конца фильма], то фильм пересоберется успешно, без нескольких последних секунд, и вот этот пересобранный видеофайл уже будет нормально воспроизводиться MPC-HC, хотя в нем ровно тот же самый видеопоток, что и в оригинальном файле с поврежденным хвостом.
Mkvtoolnix при такой пересборке пишет в лог следующую ошибку, но пересобирает успешно:
Error in the Matroska file structure at position 12461336755. Resyncing to the next level 1 element.
The last timestamp processed before the error was encountered was 01:54:20.896000000.
Resync failed: no valid Matroska level 1 element found.
Что же касается MPC-HC, то почему-то он зависает и начинает ебать жесткий диск только с теми файлами, у которых не докачаны последние несколько мегабайт в хвосте. А файлы, в которых не докачано что-то в середине, воспроизводятся абсолютно нормально. Само собой, с глюком на поврежденных местах, но по файлу можно спокойно перемещаться, и все остальные фрагменты воспроизводятся без проблем.
Что такого особенного находится в хвосте видеофайла mkv, что MPC-HC моментально детектит какую-то проблему с файлом и сходит с ума?
Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере MKV, внутри - H.264. Недокачаны потому, что в торренте - mkv с фильмом и "левый" txt-файл, и вот на этот последний кусок торрента нет сидов. Внутри самого торрента эти два файла расположены именно в таком порядке, поэтому у видеофайла не докачаны последние пара мегабайт в конце, а не первые пара мегабайт в начале, где заголовки.
Иными словами, видеофайл - с поврежденным последним 0.1%.
Вот такие видеофайлы почему-то ломают софтверный плеер MPC-HC. Фильм включается нормально, но при любой попытке скипнуть на рандомный момент или даже сменить аудиодорожку во время воспроизведения MPC-HC целиком зависает и начинает с максимальной скоростью ебать жесткий диск, на котором лежит файл.
При этом другим софтом, например, Avidemux (обертка над кодеками для линейного редактирования и перекодирования) файл открывается нормально. Как и с любым другим mkv, фильм открывается медленно (пару минут происходят операции типа Matroska clusters, Matroska images, Checking if timestamps are valid), но после завершения этих операций открытия можно скакать в любое место фильма без проблем и делать с видеорядом что угодно.
Если с помощью mkvtoolnix "пересобрать" этот видеофайл, без перекодирования, оставив все оригинальные дорожки и просто указав промежуток 00:00:00-[за несколько секунд до конца фильма], то фильм пересоберется успешно, без нескольких последних секунд, и вот этот пересобранный видеофайл уже будет нормально воспроизводиться MPC-HC, хотя в нем ровно тот же самый видеопоток, что и в оригинальном файле с поврежденным хвостом.
Mkvtoolnix при такой пересборке пишет в лог следующую ошибку, но пересобирает успешно:
Error in the Matroska file structure at position 12461336755. Resyncing to the next level 1 element.
The last timestamp processed before the error was encountered was 01:54:20.896000000.
Resync failed: no valid Matroska level 1 element found.
Что же касается MPC-HC, то почему-то он зависает и начинает ебать жесткий диск только с теми файлами, у которых не докачаны последние несколько мегабайт в хвосте. А файлы, в которых не докачано что-то в середине, воспроизводятся абсолютно нормально. Само собой, с глюком на поврежденных местах, но по файлу можно спокойно перемещаться, и все остальные фрагменты воспроизводятся без проблем.
Что такого особенного находится в хвосте видеофайла mkv, что MPC-HC моментально детектит какую-то проблему с файлом и сходит с ума?
>>19614
Я заметил такое поведение в utorrent. Когда добавляю новый торрент с многосерийным сериалом, сначала ставлю приоритет файлов по порядку, от 15 (высокий) до 1 (низкий), чтобы серии скачивались по порядку от первой и так далее. Но когда торрент стартует, utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце, только после этого начинается нормальная закачка с приоритетом на первый файл как было задано.
Это специальная фича сделанная для превью, не знаю в каком конкретно софте, но по всей видимости видео так устроено, что для открытия требуется не только начало, но и конец. И это настолько известный факт, что специально запиливают в криентах такую фичу качать в первую очередь начало и конец.
Я заметил такое поведение в utorrent. Когда добавляю новый торрент с многосерийным сериалом, сначала ставлю приоритет файлов по порядку, от 15 (высокий) до 1 (низкий), чтобы серии скачивались по порядку от первой и так далее. Но когда торрент стартует, utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце, только после этого начинается нормальная закачка с приоритетом на первый файл как было задано.
Это специальная фича сделанная для превью, не знаю в каком конкретно софте, но по всей видимости видео так устроено, что для открытия требуется не только начало, но и конец. И это настолько известный факт, что специально запиливают в криентах такую фичу качать в первую очередь начало и конец.
>>19659
Такое со всеми файлами, включая последний файл?
Просто начало N-го файла лежит в том же куске торрента, что и конец N-1-го, так что при скачивании начала одного неминуемо скачается и конец предыдущего (кроме редких случаев, когда граница файлов совпала с границами кусков).
>utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце
Такое со всеми файлами, включая последний файл?
Просто начало N-го файла лежит в том же куске торрента, что и конец N-1-го, так что при скачивании начала одного неминуемо скачается и конец предыдущего (кроме редких случаев, когда граница файлов совпала с границами кусков).
>>19698
Да, со всеми. Я специально один раз проследил, в utorrent в списке файлов и есть и диаграмма кусков, так что видно как клиент запрашивает и скачивает граничные все подряд, и пока не закончит этот процесс нормальная загрузка не начинается.
Насчет неминуемой скачки согласен, просто такая формулировка "начало и конец" была когда случайно встретил упоминание этой фичи в интернете, и кажется для другого клиента. Просто так совпало, что заметил такое странное поведение у себя, а потом встретил упоминание как фичу.
Да, со всеми. Я специально один раз проследил, в utorrent в списке файлов и есть и диаграмма кусков, так что видно как клиент запрашивает и скачивает граничные все подряд, и пока не закончит этот процесс нормальная загрузка не начинается.
Насчет неминуемой скачки согласен, просто такая формулировка "начало и конец" была когда случайно встретил упоминание этой фичи в интернете, и кажется для другого клиента. Просто так совпало, что заметил такое странное поведение у себя, а потом встретил упоминание как фичу.
>>19722
А, насчет последнего может ты и прав, правда там как раз была озвучка, которую я исключил из загрузок, но вроде последний таки не догрузился, или по крайней мере я припоминаю что висел некоторое время незагруженный.
А, насчет последнего может ты и прав, правда там как раз была озвучка, которую я исключил из загрузок, но вроде последний таки не догрузился, или по крайней мере я припоминаю что висел некоторое время незагруженный.
Как нормализацию сделать в webm for retards?
>>19562
Ясен хер, там crf 30 стоит, но качество никакого не будет с ним.
>аж в 2 раза файл меньше весит на выходе.
Ясен хер, там crf 30 стоит, но качество никакого не будет с ним.
А в линуксе можно сделать скрипт на который можно было бы перетаскивать файлы или это чисто виндовая фича?
>>19562
А если 30 заменить на 40 - то будет в четыре раза меньше или типо того, и это ещё от исходного файла зависит.
Прочитать справку по ffmpeg, и справку по bat-файлам, или просто загуглить нужный тебе функционал.
>аж в 2 раза файл меньше весит на выходе.
А если 30 заменить на 40 - то будет в четыре раза меньше или типо того, и это ещё от исходного файла зависит.
Прочитать справку по ffmpeg, и справку по bat-файлам, или просто загуглить нужный тебе функционал.
>>19883
У меня точно такой же скрипт на питоне есть, для более сложной обработки файлов, на который можно как на батник скидывать. Я не знаю есть ли такой функционал у файлменеджера люникса - но если есть, то можно конечно, потому что питон там точно работает, а что с местными батниками (там sh-скрипты вроде бы) - я не знаю.
У меня точно такой же скрипт на питоне есть, для более сложной обработки файлов, на который можно как на батник скидывать. Я не знаю есть ли такой функционал у файлменеджера люникса - но если есть, то можно конечно, потому что питон там точно работает, а что с местными батниками (там sh-скрипты вроде бы) - я не знаю.
>>19883
Я на питоне себе напердолил скрипт, который рендерит все видео, которые лежат в одной с ним папке. Не то же самое, но как вариант.
Я на питоне себе напердолил скрипт, который рендерит все видео, которые лежат в одной с ним папке. Не то же самое, но как вариант.
>>19883
Нет. Там надо открывать консоль, ручками прописывать название скрипта, а уже потом в окно консоли скидывать сам файл, после чего запустить.
Нет. Там надо открывать консоль, ручками прописывать название скрипта, а уже потом в окно консоли скидывать сам файл, после чего запустить.
Конвертирую видео1 в видео2. Хочу удалить ВСЕ метаданные нахуй. Было: пикрелейтед №1.
https://ffmpeg.org/ffmpeg.html#Advanced-options
-map_metadata -1 стирает метаданные из контейнера и стримов.
-map_chapters -1 должно стирать главы, но на деле получается пикрелейтед №2 в mediainfo глав нет, но осталось обрезанное меню навигации, а в видеоплеере пикрелейтед №3 ебаные главы до сих пор на месте.
КАК ЭТО ГОВНО ВЫРЕЗАТЬ ОДНОЙ КОМАНДОЙ?
Можно через -f ffmetadata сделать дамп метаданных, потом поправить их через блокнот и импортировать обратно, но НАХУЯ, ЕСЛИ МНЕ НАДО ПРОСТО ИХ УДАЛИТЬ?
Можно импортировать пустой файл, но это костыль.
КАК ПРОСТО СТЕРЕТЬ ИХ?
https://ffmpeg.org/ffmpeg.html#Advanced-options
-map_metadata -1 стирает метаданные из контейнера и стримов.
-map_chapters -1 должно стирать главы, но на деле получается пикрелейтед №2 в mediainfo глав нет, но осталось обрезанное меню навигации, а в видеоплеере пикрелейтед №3 ебаные главы до сих пор на месте.
КАК ЭТО ГОВНО ВЫРЕЗАТЬ ОДНОЙ КОМАНДОЙ?
Можно через -f ffmetadata сделать дамп метаданных, потом поправить их через блокнот и импортировать обратно, но НАХУЯ, ЕСЛИ МНЕ НАДО ПРОСТО ИХ УДАЛИТЬ?
Можно импортировать пустой файл, но это костыль.
КАК ПРОСТО СТЕРЕТЬ ИХ?
>>20194
удваиваю реквест кста
удваиваю реквест кста
>>20194
Ок, я разобрался, нужно добавить
-movflags disable_chpl
И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.
Ок, я разобрался, нужно добавить
-movflags disable_chpl
И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.
>>11324
С помощью винампа можно, в меню плейлиста.
С помощью винампа можно, в меню плейлиста.
>>20194
Может быть добавить флаг -dn? По идее там есть только аудио-видео-субтитры, и ещё некие данные, и вот -dn как раз про них. Может быть.
Может быть добавить флаг -dn? По идее там есть только аудио-видео-субтитры, и ещё некие данные, и вот -dn как раз про них. Может быть.
>>20250
Объясни.
> И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.
Объясни.
>>20194
mkvtoolnix
mkvtoolnix
>>20392
Для mp4 контейнера chapters для нормальных людей хранятся в формате quicktime, а для заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись, потому что им нужно выделиться из общей массы.
Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.
Для mp4 контейнера chapters для нормальных людей хранятся в формате quicktime, а для заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись, потому что им нужно выделиться из общей массы.
Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.
>>20487
Что?
> chapters для нормальных людей хранятся в формате quicktime
> заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись
Что?
>>20487
Может. Потому-что
Конченый, ни на что не способный контейнер без каких-либо преимуществ, который пропихивают срыночные пердиксы из патентной параши MPEG LA и их подсосы.
>Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.
Может. Потому-что
>mp4
Конченый, ни на что не способный контейнер без каких-либо преимуществ, который пропихивают срыночные пердиксы из патентной параши MPEG LA и их подсосы.
>>21123
Зачем повторил моё последнее предложение?
Зачем повторил моё последнее предложение?
Сап, заснял со своего шитого салями пару видосиков, а оказалось, что встроенная камера как то гробит длительность видео, но не аудио, на пикриле видеопоток длиться 59 часов, а аудио 31 секунду, сколько и должно длиться видео.
Понятное дело, любые видеоплееры охуевают от этого, и воспроизводят либо аудио, либо видео.
Ффмпега это тоже касается, он если и кодирует, то сохраняет эту длительность.
Так вот, есть ли какой то способ это исправить? Можно ли заставить ффмпег не тащить длительность видео, а составлять её самому?
Понятное дело, любые видеоплееры охуевают от этого, и воспроизводят либо аудио, либо видео.
Ффмпега это тоже касается, он если и кодирует, то сохраняет эту длительность.
Так вот, есть ли какой то способ это исправить? Можно ли заставить ффмпег не тащить длительность видео, а составлять её самому?
>>21917
Пики отклеились.
Пики отклеились.
>>21917
Ну есть один способ , но он какой-то дебильный, если кто-то знает получше подскажите
ffmpeg -i video.mp4 -c copy 1.h264
ffmpeg -i video.mp4 -c copy 1.aac
ffmpeg -r 60 -i 1.h264 -i 1.aac -c copy out.mp4
Ну есть один способ , но он какой-то дебильный, если кто-то знает получше подскажите
ffmpeg -i video.mp4 -c copy 1.h264
ffmpeg -i video.mp4 -c copy 1.aac
ffmpeg -r 60 -i 1.h264 -i 1.aac -c copy out.mp4
>>21996
Пасиба, добрый анон. Правда пришлось ещё видео повернуть, но это просто.
Пасиба, добрый анон. Правда пришлось ещё видео повернуть, но это просто.
>>24175
Угу там действительно много вычислений требуется.
Есть кодеки, которые прессую карточку, а процессор уже поменьше - но они отличаются плохим качеством по соотношению размера файла к качеству изображения.
Угу там действительно много вычислений требуется.
Есть кодеки, которые прессую карточку, а процессор уже поменьше - но они отличаются плохим качеством по соотношению размера файла к качеству изображения.
ffmpeg.exe -i 123.aif -c:a alac 123.m4a
Нуб в треде. Такая команда будет идентична исходнику или нет? Мне бы в идеале распакуя обратно m4a в aif, чтоб спектр вообще был неизменным. Или все таки после этого уже не будет идентичен?
Нуб в треде. Такая команда будет идентична исходнику или нет? Мне бы в идеале распакуя обратно m4a в aif, чтоб спектр вообще был неизменным. Или все таки после этого уже не будет идентичен?
>>24697
В 99% неизменно, нет только если там какие-то специфичные 32 бит и подобное
В 99% неизменно, нет только если там какие-то специфичные 32 бит и подобное
>>24697
Можно проверить такой клмандой:
ffmpeg -i 1.aif -f hash -
ffmpeg -i 1.m4a -f hash -
Если одинаковый хеш то не изменилось
Можно проверить такой клмандой:
ffmpeg -i 1.aif -f hash -
ffmpeg -i 1.m4a -f hash -
Если одинаковый хеш то не изменилось
313 Кб, 1300x1824Хочу сделать "энкод-бокс", который будет кодировать мою коллекцию старого европейского артхауса, мож ещё аниме и гачимуча порн. Плнирую кодировать через AOM. Какое железо по бомжу и одновременно мощное лучше взяь в такой бокс? Ряженку новую, ряженку старую, мож какие интолы?
>>25210
Значит так. Можешь брать сразу тредрипер, и 128 ГБ ОЗУ. Запускаешь на этом av1an, и при правильной настройке он будет загружать сразу все эти потоки, ну и молись чтобы оно не полезло в своп.
Значит так. Можешь брать сразу тредрипер, и 128 ГБ ОЗУ. Запускаешь на этом av1an, и при правильной настройке он будет загружать сразу все эти потоки, ну и молись чтобы оно не полезло в своп.
>>25224
Не, ну можно конечно взяьт с алик 2*EPYC 7601, но нафига мне такая дура? По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.
Хз что это такое. По моим тестам AOM лучше работает с грэйном.
Не, ну можно конечно взяьт с алик 2*EPYC 7601, но нафига мне такая дура? По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.
>av1an
Хз что это такое. По моим тестам AOM лучше работает с грэйном.
>>25255
Ну у голого aomenc с паралелизмом дела обстоят не очень. Можно конечно врубить tiles, но это ухудшает качество.
Если ты собираешься запускать голый aomenc, то лучше новых топовых интелов не найти.
Но если тебе нужно расскрыть потенциал твоего проца на максимум, тогда тебе придётся осилить av1an. Так то что av1an, что svt оба делят видео на GOP и кодируют их параллельно.
Ну у голого aomenc с паралелизмом дела обстоят не очень. Можно конечно врубить tiles, но это ухудшает качество.
Если ты собираешься запускать голый aomenc, то лучше новых топовых интелов не найти.
Но если тебе нужно расскрыть потенциал твоего проца на максимум, тогда тебе придётся осилить av1an. Так то что av1an, что svt оба делят видео на GOP и кодируют их параллельно.
>>25255
Так не бывает. Тут либо файлопомойка, либо сервер нахуй.
> По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.
Так не бывает. Тут либо файлопомойка, либо сервер нахуй.
98 Кб, 1081x654>>25314
Действительно... С другой стороны это облегчает выбор, на нужно гнаться за многоядами. Какой-нить 11600k с рук, раскочегареный по одному ядру наверное оптимально зайдёт.
>Ну у голого aomenc с паралелизмом дела обстоят не очень.
Действительно... С другой стороны это облегчает выбор, на нужно гнаться за многоядами. Какой-нить 11600k с рук, раскочегареный по одному ядру наверное оптимально зайдёт.
>>25210
Дешевле всего купить зион с большим количеством донных ядер. Конечно нормальный современный комп лучше справится
>>25255
Переможный костыль для убогого кодировщика которая делит видео на множество маленьких чтоб нагрузить все ядра
Дешевле всего купить зион с большим количеством донных ядер. Конечно нормальный современный комп лучше справится
>>25255
> Хз что это такое. По моим тестам AOM лучше работает с грэйном.
Переможный костыль для убогого кодировщика которая делит видео на множество маленьких чтоб нагрузить все ядра
>>25681
В строчке дополнительных параметров указать нужный фильтр (их несколько вроде как) нормализации ffmpeg с нужными параметрами. То есть так же как и в чистом ffmpeg.
Никакого интерфейса для этого может и не быть
В строчке дополнительных параметров указать нужный фильтр (их несколько вроде как) нормализации ffmpeg с нужными параметрами. То есть так же как и в чистом ffmpeg.
Никакого интерфейса для этого может и не быть
>>25792
Тогда никак. Ограничение интерфейса твоей программы или просто твоей программы, она не может выполнить твою задачу.
Тогда никак. Ограничение интерфейса твоей программы или просто твоей программы, она не может выполнить твою задачу.
Как пережать свою коллекцию порнухи, максимально сохранив качество и уменьшив размер файла? Да ещё в идеале используя квик синк, чтобы побыстрей?
>>26327
Ранее консилиум сжатиешизиков обсуждал данный вопрос. В ходе обсуждений был сделан следующий вывод: лучший способ сжатия видеоархива - купить жёсткий диск.
Ранее консилиум сжатиешизиков обсуждал данный вопрос. В ходе обсуждений был сделан следующий вывод: лучший способ сжатия видеоархива - купить жёсткий диск.
>>26327
Ты попросил невозможного, выбери два пункта:
Максимальное качество
Низкий размер
Быстрота кодирования
Ты попросил невозможного, выбери два пункта:
Максимальное качество
Низкий размер
Быстрота кодирования
>>26327
в 720p crf23-28
в 720p crf23-28
>>26327
я не автор вопроса, но интересен вариант: Максимальное качество+низкий размер - подозреваю что надо в сторону H265 копать, но если кто в теме более детальных параметров для заданной цели, рад был бы узнать
я не автор вопроса, но интересен вариант: Максимальное качество+низкий размер - подозреваю что надо в сторону H265 копать, но если кто в теме более детальных параметров для заданной цели, рад был бы узнать
>>26519
>>26521
интересуют также отличия настроек в зависимости от конента, например если у нас не домашнее кино про немцев, а туториалы, о том как домбить бомбас качать кино про немцев баз смс и регистрации, где много текста на экране и мало динамики, бо то качество в котором кино можно смотреть может быть для текста нечитабельно, скорость кодирования думаю проблемой не будет, при наличии NVENC, и МНОГАЯДЕР у процессора...
>>26521
интересуют также отличия настроек в зависимости от конента, например если у нас не домашнее кино про немцев, а туториалы, о том как домбить бомбас качать кино про немцев баз смс и регистрации, где много текста на экране и мало динамики, бо то качество в котором кино можно смотреть может быть для текста нечитабельно, скорость кодирования думаю проблемой не будет, при наличии NVENC, и МНОГАЯДЕР у процессора...
>>26533
Чтобы умереть от старости даже собирать ничего не надо - av1 через libaom на veryslow сгодится.
Чтобы умереть от старости даже собирать ничего не надо - av1 через libaom на veryslow сгодится.
>>26534
а профиты то от av1 veryslow будут? так то дурной задачей можно всегда себя нагрузить, вопрос то в профитности затеи, насколько например будет прирост компрессии в сравнении с кодекнейм, ну и без более детального указания параметров тоже вопросы возникают - или мы Лузлесс кодируем или определенное ограничение качества ставим...
>>26533
а здесь немного я не понял прекола, зачем нам xhe-acc с аудио по моему вообще проблем особыхх нету как по мне, и маста аудио дорога занимает на порядок меньше... вопрос еще к воспроизводимости контента возникает, а то можно такого накодировать что ничем не откроется... и какой тогда смысл этого всего...
а профиты то от av1 veryslow будут? так то дурной задачей можно всегда себя нагрузить, вопрос то в профитности затеи, насколько например будет прирост компрессии в сравнении с кодекнейм, ну и без более детального указания параметров тоже вопросы возникают - или мы Лузлесс кодируем или определенное ограничение качества ставим...
>>26533
а здесь немного я не понял прекола, зачем нам xhe-acc с аудио по моему вообще проблем особыхх нету как по мне, и маста аудио дорога занимает на порядок меньше... вопрос еще к воспроизводимости контента возникает, а то можно такого накодировать что ничем не откроется... и какой тогда смысл этого всего...
>>26534
Потестил AV1 - для него норм кодировщик надо, потому что одни умеют 24 потока заюзать, а другие непонятно чем занимаются во время кодирования и оно капец долгое выходит... но уменьшение размера впечатляет, хотя разница в качестве на глаз заметна даже...
>>26583
тогда остается только HEVC Loseless для качества, ну или с высоким качеством на крайняк... av1 хорош на случай когда и места жалко, но и файл пусть полежит...
Потестил AV1 - для него норм кодировщик надо, потому что одни умеют 24 потока заюзать, а другие непонятно чем занимаются во время кодирования и оно капец долгое выходит... но уменьшение размера впечатляет, хотя разница в качестве на глаз заметна даже...
>>26583
тогда остается только HEVC Loseless для качества, ну или с высоким качеством на крайняк... av1 хорош на случай когда и места жалко, но и файл пусть полежит...
>>26588
Там два енкодера av1 если что. libaom-av1 референсный, был в основном добавлен для тестов. Овердохуя медленный, но жмет как надо. И libsvtav1 - над ним еще активно работают, но в последних версиях ffmpeg (5.1+) он уже довольно прилично работает и шустро.
crf поменьше?
Там два енкодера av1 если что. libaom-av1 референсный, был в основном добавлен для тестов. Овердохуя медленный, но жмет как надо. И libsvtav1 - над ним еще активно работают, но в последних версиях ffmpeg (5.1+) он уже довольно прилично работает и шустро.
> хотя разница в качестве на глаз заметна даже...
crf поменьше?
>>26590
та вроде в 0 до упора (я вообще HANDBRAKE юзал для конвертации, не хочу с терминалом возится на винде), но с 30 мб до 1 сжать это конечно сильное заявление на успех...
та вроде в 0 до упора (я вообще HANDBRAKE юзал для конвертации, не хочу с терминалом возится на винде), но с 30 мб до 1 сжать это конечно сильное заявление на успех...
>>26590
по качеству хотя может то HEVC чего намутил, с которым сравнивал, бо HEVC как будто подтянул четкость или контраст, но это не точно...
по факту все экспериментально походу решать надо... так как не все настройки всем подходят...
по качеству хотя может то HEVC чего намутил, с которым сравнивал, бо HEVC как будто подтянул четкость или контраст, но это не точно...
по факту все экспериментально походу решать надо... так как не все настройки всем подходят...
>>26667 (Del)
Побеждает, конечно. Только попробуй найди этот Tencent V265 или Pheonix265, QAV1, чтобы можно было сжимать в него.
Побеждает, конечно. Только попробуй найди этот Tencent V265 или Pheonix265, QAV1, чтобы можно было сжимать в него.
>>26667 (Del)
Что-то не вкурю почему или 4:1:1 на скрине или 6:1:1 куда ж с такой субдискретизацией сунуться - эт дичь какая-то выходит... И так ли велика разница проприетарщины и опенсорса
Что-то не вкурю почему или 4:1:1 на скрине или 6:1:1 куда ж с такой субдискретизацией сунуться - эт дичь какая-то выходит... И так ли велика разница проприетарщины и опенсорса
>>26659 (Del)
В импортных железках? В любом случае, если это н
хардварные имплементации, то они сосут бибарандум у софтовых реализаций.
В импортных железках? В любом случае, если это н
хардварные имплементации, то они сосут бибарандум у софтовых реализаций.
>>26667 (Del)
Мне даже интересно, где они эти hw266 достали и на какой процессере или плеере воспроизводили вообще какой производительностью
Мне даже интересно, где они эти hw266 достали и на какой процессере или плеере воспроизводили вообще какой производительностью
Анончики, приветствую!
В общем, есть около 15000 файлов в mp3 и звук который нужно наложить поверх этих файлов, типа вотермарки которая будет звучать поверх музыки. Как это реализовать массово? Чтобы не вбивать по файлику, а вхуячить папку входа и папку выхода с теми же названиями файлов по итогу?
Если есть более простое решение - буду премного благодарен, поскольку несколько дней гугления ни к чему не привело. Либо я находил программы без описания работы, либо решения которые делают только по одному файлу за раз.
В общем, есть около 15000 файлов в mp3 и звук который нужно наложить поверх этих файлов, типа вотермарки которая будет звучать поверх музыки. Как это реализовать массово? Чтобы не вбивать по файлику, а вхуячить папку входа и папку выхода с теми же названиями файлов по итогу?
Если есть более простое решение - буду премного благодарен, поскольку несколько дней гугления ни к чему не привело. Либо я находил программы без описания работы, либо решения которые делают только по одному файлу за раз.
>>27514
ffmpeg batch av converter, там все есть, и кодирование в твоих настройках, и генерация древа папок из сорса, плюс одновременное кодирование в отличии от обычного ффпмег, либо батник пердоль. Для себя лучше не нашел.
ffmpeg batch av converter, там все есть, и кодирование в твоих настройках, и генерация древа папок из сорса, плюс одновременное кодирование в отличии от обычного ффпмег, либо батник пердоль. Для себя лучше не нашел.
>>27531
Параллельное кодирование точнее. Не дописал, что сам кодировал 36к ogg файлов в opus. Довольно быстро сделал в 24 потока.
>одновременное кодирование
Параллельное кодирование точнее. Не дописал, что сам кодировал 36к ogg файлов в opus. Довольно быстро сделал в 24 потока.
Надо захватить звук с ютуба. Именно какой он на ютубе, а не мп3 который предлагают разные сервисы по скачиванию с ютуба.
Что мне потребуется? Я так понимаю, это вполне возможно, если знать что вбить в командную строку.
Что мне потребуется? Я так понимаю, это вполне возможно, если знать что вбить в командную строку.
>>27611
На телефоне NewPipe без командной строки, на компьютере - да, yt-dlp -F и yt-dlp -x --audio-format=
На телефоне NewPipe без командной строки, на компьютере - да, yt-dlp -F и yt-dlp -x --audio-format=
>>15043
Однажды сработало, а щас не работает. Стрим рекорд не дает скачать стрим с ограничением по возрасту, а дамп кэш вообще пишет: опция не найдена.
Однажды сработало, а щас не работает. Стрим рекорд не дает скачать стрим с ограничением по возрасту, а дамп кэш вообще пишет: опция не найдена.
Сап ананасы! Давно забыл комманду для объединения двух видосов в одно так чтоб одновременно проигрывались да, я про увеличение резрешения видево и нагуглить не получается. Вообще мне сейчас понадобилось не видео объединить а две гифки одинаковых размеров. Выручай анонч с меня как обычно
Спалите быдлу — в каком формате писать/конвертировать видео малого размера, чтобы не сыпалось квадратами.
Мой фаворит это порнуха высотой кадра 180. Высокая продолжительность видеоряда, но всё различимо и без квадратов. Хочу так же.
Мой фаворит это порнуха высотой кадра 180. Высокая продолжительность видеоряда, но всё различимо и без квадратов. Хочу так же.
>>30025
Во-первых есть AV1 который всем его лучше, а во-вторых оба не подходят для указанной задачи, потому что очень любят мылить картинку.
Во-первых есть AV1 который всем его лучше, а во-вторых оба не подходят для указанной задачи, потому что очень любят мылить картинку.
>>30033
Ну да, так и делают. 320x180 ставят на 25 минут чтобы картинка не сыпалась на квадраты на таких битрейтах. Если просто взять и при том же битрейте поставить 360p, то чёткость от этого не увеличиться, а артефакты полезут со всех щелей.
Ну да, так и делают. 320x180 ставят на 25 минут чтобы картинка не сыпалась на квадраты на таких битрейтах. Если просто взять и при том же битрейте поставить 360p, то чёткость от этого не увеличиться, а артефакты полезут со всех щелей.
>>05384 (OP)
Сжал только что сохранения для игры Rimworld - 6495 Мб превратились в 56 Мб. Я конечно любитель сжимать сжимаемое, но это уже чересчур.
Сжал только что сохранения для игры Rimworld - 6495 Мб превратились в 56 Мб. Я конечно любитель сжимать сжимаемое, но это уже чересчур.
>>30738
Чтобы картинка выглядела лучше — нужно потратить больше битрейта. Битрейт определяет количество информации, которое будет закодировано. И поставь ты хоть 1080p, но на 128kbps картинка будет выглядеть мыльным говнищем.
Чтобы картинка выглядела лучше — нужно потратить больше битрейта. Битрейт определяет количество информации, которое будет закодировано. И поставь ты хоть 1080p, но на 128kbps картинка будет выглядеть мыльным говнищем.
>>30910
При этом в 1080 она будет выглядеть лучше чем в 240. Потому что у кодировщика есть больше данных, больше разрешение чтоб разгуляться. Могу даже показать пример
При этом в 1080 она будет выглядеть лучше чем в 240. Потому что у кодировщика есть больше данных, больше разрешение чтоб разгуляться. Могу даже показать пример
>>31039
Ну давай, показывай пример.
Ну давай, показывай пример.
>>30819
Ожидаемо, там же все сохранения - однотипные XML файлы, к тому же не инкрементальные
Ожидаемо, там же все сохранения - однотипные XML файлы, к тому же не инкрементальные
88 Кб, 1280x720Почему телек некоторые файлы проигрывает без нареканий, а некоторые ругает ("тип файла не поддерживается"). Контейнеры ведь одинаковы, формат одинаков. Различаются файлы на каком-то наноуровне, которые не виден в свойствах?
>>32057
Очевидно что формат не одинаков. У многих кодеков есть вагон и маленькая тележка профилей, добавляют их со временем, поэтому в старых железках/софтинах может не быть поддержки. Как в свое время было с 10 бит в h264.
Очевидно что формат не одинаков. У многих кодеков есть вагон и маленькая тележка профилей, добавляют их со временем, поэтому в старых железках/софтинах может не быть поддержки. Как в свое время было с 10 бит в h264.
>>31779
Попробуй youtube dlp. Но я не пробовал.
Попробуй youtube dlp. Но я не пробовал.
>>31779
в этом или прошлом треде было. Через mpv
в этом или прошлом треде было. Через mpv
Как сжать видео не просрав качество?
Снял минуту обс в мкв, 115 мб - конвернтул ффмпг в мп4 - 50мб, двощ все равно не грузит. Что делать?бочку
Снял минуту обс в мкв, 115 мб - конвернтул ффмпг в мп4 - 50мб, двощ все равно не грузит. Что делать?бочку
>>32974
Идти читать что такое контейнеры и кодеки, чем они отличаются, как задавать качество/битрейт в ffmpeg для них, а так же - какие форматы поддерживает двощ.
Дожили - неграмотные линуксойды домохозяйки.
> мкв
> мп4
> Что делать?
Идти читать что такое контейнеры и кодеки, чем они отличаются, как задавать качество/битрейт в ffmpeg для них, а так же - какие форматы поддерживает двощ.
> (Linux: Firefox based)
Дожили - неграмотные линуксойды домохозяйки.
>>33014
Задаю конкретный вопрос в целевом треде.
Я всю жизнь занимался совсем другой темой, вот и спросил, а нонейм мне говна вылил, хотя явно мог бы правильные ключи для ффмпг сказать. Пшел нахуй.
Задаю конкретный вопрос в целевом треде.
Я всю жизнь занимался совсем другой темой, вот и спросил, а нонейм мне говна вылил, хотя явно мог бы правильные ключи для ффмпг сказать. Пшел нахуй.
>>33025
Пруф несёшь, что не бесполезный кусок говна и не трепло. Тогда подумаем, сказать тебе ключи или нет.
> Я всю жизнь занимался совсем другой темой
Пруф несёшь, что не бесполезный кусок говна и не трепло. Тогда подумаем, сказать тебе ключи или нет.
>>33025
Если ты даже в элементарных вещах в кодировании ничего не понимаешь, значит, несмотря на то что результата ты хочешь и какого получше,вообще не утрудил себя почитать ничего по теме. Сразу побежал требовать чтоб за тебя все сделали зашибись, а ты сидел шиковал на всем готовом. Никакого желания объяснять азы тому кто не желает учиться нет. Качай какой-нибудь WebM for Retards, тебе хватит.
Если ты даже в элементарных вещах в кодировании ничего не понимаешь, значит, несмотря на то что результата ты хочешь и какого получше,вообще не утрудил себя почитать ничего по теме. Сразу побежал требовать чтоб за тебя все сделали зашибись, а ты сидел шиковал на всем готовом. Никакого желания объяснять азы тому кто не желает учиться нет. Качай какой-нибудь WebM for Retards, тебе хватит.
frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
Что с этим говном делать? Почему при первом проходе и начале второго не показывает ни номер фрейма, ни время?
frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
Что с этим говном делать? Почему при первом проходе и начале второго не показывает ни номер фрейма, ни время?
>>33312
Раньше было, а после какой-то обновы перестало показывать. А мне нужно процесс контролировать, проценты выводить. Где мои проценты?
Раньше было, а после какой-то обновы перестало показывать. А мне нужно процесс контролировать, проценты выводить. Где мои проценты?
>>33008
Что значит немного больше? Мне битрейт рассчитать надо.
Например, на одну минуту у тебя уйдёт 2.8 мегабит.
Что значит немного больше? Мне битрейт рассчитать надо.
Например, на одну минуту у тебя уйдёт 2.8 мегабит.
>>33412
REPLACE THE AUDIO
@
NO PROBLEM
@
FIX THE IMAGE
@
NO PROBLEM
@
CONVERT THE VIDEO
@
NO PROBLEM
@
CONCAT A PNG SEQUENCE
@
NO PROBLEM
@
CREATE A NON-PLAYABLE FILE
@
NO PROBLEM
REPLACE THE AUDIO
@
NO PROBLEM
@
FIX THE IMAGE
@
NO PROBLEM
@
CONVERT THE VIDEO
@
NO PROBLEM
@
CONCAT A PNG SEQUENCE
@
NO PROBLEM
@
CREATE A NON-PLAYABLE FILE
@
NO PROBLEM
>>33412
Premiere Pro has the worst encoders ON THIS PLANET
Premiere Pro has the worst encoders ON THIS PLANET
>>33363
Сколько пользовался четвертой версией, всегда так было
Сколько пользовался четвертой версией, всегда так было
>>34515
Да ну. Ты ещё расскажи что Premier Pro умеет рендерить в WEBM. И не просто рендерит, но и поддерживает уникальные особенности этого формата, вроде смены разрешения видеокадра на лету.
> В видеоредакторе.
Да ну. Ты ещё расскажи что Premier Pro умеет рендерить в WEBM. И не просто рендерит, но и поддерживает уникальные особенности этого формата, вроде смены разрешения видеокадра на лету.
>>34576
Значит не Premier Pro
Значит не Premier Pro
>>34576
К премьеру можно подрубить воукодер или даже ффмпег (через костыли). Полгода давился давинчи, заебало врать себе что он не дерьмо собачье. Вернулся на премьер.
К премьеру можно подрубить воукодер или даже ффмпег (через костыли). Полгода давился давинчи, заебало врать себе что он не дерьмо собачье. Вернулся на премьер.
11 Кб, 1015x87>>35854
Найти детектор потока, расширение для браузера, скорми ссылку в ffmpeg как у меня примерно и запусти. -t и -ss по крайне мере на твитче поддерживаются.
Предположу что youtube-dl справится тоже, скорми ссылку с флагом -F, посмотри даёт ли он форматы. Ещё youtube-dl умеет выдавать ссылку без запуска браузера. Но если загружать прямо через youtube-dl он не умеет обрезать часть стрима до загрузки.
Найти детектор потока, расширение для браузера, скорми ссылку в ffmpeg как у меня примерно и запусти. -t и -ss по крайне мере на твитче поддерживаются.
Предположу что youtube-dl справится тоже, скорми ссылку с флагом -F, посмотри даёт ли он форматы. Ещё youtube-dl умеет выдавать ссылку без запуска браузера. Но если загружать прямо через youtube-dl он не умеет обрезать часть стрима до загрузки.
>>35907
Что-то от bit stream format, наверное.
Что-то от bit stream format, наверное.
>>35953
yt-dlp.exe --username ИМЯ --password ПАРОЛЬ ...
yt-dlp.exe --username ИМЯ --password ПАРОЛЬ ...
Доброе. Надо объединить видео и аудио без нюансов и без потерь качества, без сжатия. FFmpeg справляется с данной задачей? Еще год назад объединил для сравнения в премьере и в ffmpeg, звук отличался точно.
>>36727
Конечно.
ffmpeg -i video.xyz -i sound.uvw -c copy output.mkv
>FFmpeg справляется с данной задачей?
Конечно.
ffmpeg -i video.xyz -i sound.uvw -c copy output.mkv
68 Кб, mp4,404x454, 0:03
Скиньте плиз строку для кодирования аудио + статичная картинка, в webm. Желательно чтобы ширину картинки указать и время вырезания. В гугле куча разных, но не нашёл идеальную.
Дошли руки до перекодирования запасов порнухи в HEVC. Занятно, что примерно 90% видосов в fullHD и выше сжались на 10-40%. А вот старые всякие с 480p порой даже распухли по сравнению с олдовыми версиями на ископаемых кодеках.
>>38232
ffmpeg -loop 1 -r 1 -i "cover.jpg" -i "music.flac" -t 00:04:05.23 -c:v libvpx-vp9 -pix_fmt yuv420p -colorspace bt709 -vf scale="720:720" -c:a libopus -b:a 128k -map_metadata 1 -shortest "OUTPUT.webm"
если гиф, то у меня двухпроходное
ffmpeg -loop 1 -r 1 -i "cover.jpg" -i "music.flac" -t 00:04:05.23 -c:v libvpx-vp9 -pix_fmt yuv420p -colorspace bt709 -vf scale="720:720" -c:a libopus -b:a 128k -map_metadata 1 -shortest "OUTPUT.webm"
если гиф, то у меня двухпроходное
>>38517
только чтобы тупо сэкономить место на hdd. сейчас такие exos на 6 тб каких-то запредельных денег стоят. так что перекодировка экономнее, чем второй покупать
только чтобы тупо сэкономить место на hdd. сейчас такие exos на 6 тб каких-то запредельных денег стоят. так что перекодировка экономнее, чем второй покупать
167 Кб, 375x479>>38521
Может просто меньше дрочить? Я картинки то сохранённые второй раз редко открываю, а тут аж порнуху терабайтами пересматривать
Может просто меньше дрочить? Я картинки то сохранённые второй раз редко открываю, а тут аж порнуху терабайтами пересматривать
>>13552
Для ускорения этого нужно выбирать best, а не dash, но это 720p всего. А еще вот такую строку:
https://paste.debian.net/plainh/951b739a
Ты же запсукаешь сразу два потока отдельные экстракты видео и аудио, более того - dash на ютубе железно ограниченные скоростью, из-за этого тоже долго, да и то что dl/dlp скомпилированный упакованный exe с тысячами скриптов, пока он расчехлится тоже уходит время.
Для ускорения этого нужно выбирать best, а не dash, но это 720p всего. А еще вот такую строку:
https://paste.debian.net/plainh/951b739a
Ты же запсукаешь сразу два потока отдельные экстракты видео и аудио, более того - dash на ютубе железно ограниченные скоростью, из-за этого тоже долго, да и то что dl/dlp скомпилированный упакованный exe с тысячами скриптов, пока он расчехлится тоже уходит время.
445 Кб, 828x1025>>39335
Зачем вообще кодировать?
Зачем вообще кодировать?
>>39335
Видосы с мобилки.
Мобилка без процессора, потому там часто константный битрейт громадный и сжатие очень условное, чтобы оно успевало в реальном времени кодировать - после перекодирования часто можно без заметных потерь раз в 5-10 пожать.
Видосы с мобилки.
Мобилка без процессора, потому там часто константный битрейт громадный и сжатие очень условное, чтобы оно успевало в реальном времени кодировать - после перекодирования часто можно без заметных потерь раз в 5-10 пожать.
>>39335
Шебмы для харкача.
Шебмы для харкача.
>>49474
И чё?
И чё?
>>39335
порно личное снятое на профессиональную камеру надеюсь? или ты блюреи японские рипаешь?
порно личное снятое на профессиональную камеру надеюсь? или ты блюреи японские рипаешь?
>>38499
после того как ты провел тесты на разных битрейтах и выбрал приемлемый для тебя уровень качества?
кстати скиньте софт для таких тестов. я только знаю что сравнивать видосы можно в kinovea (привет из 2004) и ICAT (не поддерживает даже h265 лул)
вот бы новые видеокодеки с беспотерьной совместимостью со старыми как jpeg xl... я недавно нагулил в егоном треде что был такой для пережатия h264 в тот же формат но не особо много экономил.
после того как ты провел тесты на разных битрейтах и выбрал приемлемый для тебя уровень качества?
кстати скиньте софт для таких тестов. я только знаю что сравнивать видосы можно в kinovea (привет из 2004) и ICAT (не поддерживает даже h265 лул)
вот бы новые видеокодеки с беспотерьной совместимостью со старыми как jpeg xl... я недавно нагулил в егоном треде что был такой для пережатия h264 в тот же формат но не особо много экономил.
Тред утонул или удален.
Это копия, сохраненная 28 января 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 28 января 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.