Этого треда уже нет.
Это копия, сохраненная 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
72 Кб, 250x250FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 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 - здесь ты найдёшь детальные методички в step-by-step how-to стиле для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также очень много вопросов отвечено на стековерфло.
Самые ходовые видео-кодеки на данный момент - VP9 и H.264. Подробный разбор их режимов кодирования читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда: https://github.com/pituz/webm-thread/wiki
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода батла HEVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Бонусом сразу вброшу youtube-dl - утилита для нормального выкачивания видео с ютуба, вк, порнхаба и ещё миллиона других видеосервисов. Не совсем кодирование, но скорее всего ты тоже этим дерьмом занимаешься, если что-то делаешь с видео, т.ч. давай осваивай тоже нормальную утилиту вместо просмотра рекламы и установки зондов. Тоже опенсорс подо всё, что способно выполнять AND NOT и XOR.
Тред №..: https://2ch.hk/s/arch/2020-08-05/res/2591244.html (
М)
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html (М)
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички в step-by-step how-to стиле для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также очень много вопросов отвечено на стековерфло.
Самые ходовые видео-кодеки на данный момент - VP9 и H.264. Подробный разбор их режимов кодирования читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда: https://github.com/pituz/webm-thread/wiki
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода батла HEVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Бонусом сразу вброшу youtube-dl - утилита для нормального выкачивания видео с ютуба, вк, порнхаба и ещё миллиона других видеосервисов. Не совсем кодирование, но скорее всего ты тоже этим дерьмом занимаешься, если что-то делаешь с видео, т.ч. давай осваивай тоже нормальную утилиту вместо просмотра рекламы и установки зондов. Тоже опенсорс подо всё, что способно выполнять AND NOT и XOR.
Тред №..: https://2ch.hk/s/arch/2020-08-05/res/2591244.html (
М)Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html (
М)Вместо libx264 пишешь h264_amf и видос кодит уже радик.
Для h265 hvec_amf пишется, если его умеет видюха конечно. Старые не умеют.
Сраная зелень работает через h264_nvenc
Для h265 hvec_amf пишется, если его умеет видюха конечно. Старые не умеют.
Сраная зелень работает через h264_nvenc
Хочу повернуть вертикальное видео. Делаю -vf transpose и у меня получается крошечное видео. Будто разрешение то же остается, а не поворачивается. Как повернуть нормально?
Когда там 266 уже выйдет?
Перекодировка там будет занимать примерно вечность?
Перекодировка там будет занимать примерно вечность?
>>2981804
Нет, просто будет как с H.265 и VP9 каждый продукт в своей нише. Один для носителей, другой для интернет-видео, ибо патенты.
Нет, просто будет как с H.265 и VP9 каждый продукт в своей нише. Один для носителей, другой для интернет-видео, ибо патенты.
Mediainfo открывается в оконном режиме при запуске из контекстного меню медиафайла. Как заставить его открываться в полноэкранном?
>>2982226
И ещё хотелось бы получить параметр командной строки, позволяющий открыть в Mediainfo выбранные файлы с видом "дерево", если по-умолчанию установлен вид "текст".
И ещё хотелось бы получить параметр командной строки, позволяющий открыть в Mediainfo выбранные файлы с видом "дерево", если по-умолчанию установлен вид "текст".
>>2982187
Видел решение в предыдущих тредах. Принеси сюда, если найдёшь.
Видел решение в предыдущих тредах. Принеси сюда, если найдёшь.
>>2979843 (OP)
Какой кодек имеет наилучшее сжатие с наименьшими потерями? Какой кодек имеет наилучшее сжатие с наименьшими потерями и адекватной нагрузкой на железо?
Какой кодек имеет наилучшее сжатие с наименьшими потерями? Какой кодек имеет наилучшее сжатие с наименьшими потерями и адекватной нагрузкой на железо?
тест
>>2983077
av1
h.265
>Какой кодек имеет наилучшее сжатие с наименьшими потерями?
av1
>Какой кодек имеет наилучшее сжатие с наименьшими потерями и адекватной нагрузкой на железо?
h.265
>>2982085
Потому что в нем не реализована даже половина того, что в хуй264 есть. Нет нормального деблокинга, нет оценки и компенсации движения, нет предсказания кадров, за 6 лет, сука, не смогли сделать нормальный однопроходный алгоритм. Я еще что-то про квантизацию хотел написать, но о мертвых либо хорошо, либо никак. Я тут один видос на ютабе смотрел, так там темная сцена в вп9 просто засрана ебучим бандингом. Гугл там вообще это говно разрабатывает или че?
>>2982134
Потому что для адекватного кодирования тебе нужен суперкомпьютер.
Говно без задач, но лучше ав1.
Потому что в нем не реализована даже половина того, что в хуй264 есть. Нет нормального деблокинга, нет оценки и компенсации движения, нет предсказания кадров, за 6 лет, сука, не смогли сделать нормальный однопроходный алгоритм. Я еще что-то про квантизацию хотел написать, но о мертвых либо хорошо, либо никак. Я тут один видос на ютабе смотрел, так там темная сцена в вп9 просто засрана ебучим бандингом. Гугл там вообще это говно разрабатывает или че?
>>2982134
>А почему av1 - это хбз?
Потому что для адекватного кодирования тебе нужен суперкомпьютер.
>266
Говно без задач, но лучше ав1.
>>2983204
А когда-то давно, ещё до MP4 AVC / h264, в сравнении с MP4 ASP / Xvid, его дальний предок On2 VP5 - давал наименее артефачную картинку на репаках DVD9 снятых проф.видеокамерой в сложных концертных условиях. А потом их купили и чёт всё скатили.
А когда-то давно, ещё до MP4 AVC / h264, в сравнении с MP4 ASP / Xvid, его дальний предок On2 VP5 - давал наименее артефачную картинку на репаках DVD9 снятых проф.видеокамерой в сложных концертных условиях. А потом их купили и чёт всё скатили.
>>2982187
Бамп вопросу. В прошлых тредах - хуита. Если картинка не зависает, то звук.
Бамп вопросу. В прошлых тредах - хуита. Если картинка не зависает, то звук.
>>2983309
На рутрекере есть специальный тред с инструкциями же. Основное требование - совместимость с уровнями, наиболее широко поддерживаемыми бытовым оборудованием.
На рутрекере есть специальный тред с инструкциями же. Основное требование - совместимость с уровнями, наиболее широко поддерживаемыми бытовым оборудованием.
Кто-нибудь пробовал с помощью av1an кодировать в vvc? Сколько занимает времени на разных предметах? К примеру, если взять 10 минутное видео
>>2983465
Ты бы хоть параметры спросил для сравнения. Про битрейт в курсе? Про пресеты? Про срф?
>К примеру, если взять 10 минутное видео
Ты бы хоть параметры спросил для сравнения. Про битрейт в курсе? Про пресеты? Про срф?
>>2983926
Ну ок. К примеру на пресете эквивалентным пресету medium и veryslow для h.264(не в курсе как они у vvc обзываются)
Про crfв курсе. Не знаю, какой выбрать. Пусть будет 25, например.
Мне просто нужно оценить пиздецовость времени на кодировку
Ну ок. К примеру на пресете эквивалентным пресету medium и veryslow для h.264(не в курсе как они у vvc обзываются)
Про crfв курсе. Не знаю, какой выбрать. Пусть будет 25, например.
Мне просто нужно оценить пиздецовость времени на кодировку
33,5 Мб, 1024x576продублирую. как сделать так чтобы небоскребы не дрожали? как ни пробовал все равно такой эффект есть.
..\ffmpeg -ss 00:47:00 -i %FILE% -to 00:02:00 ^
-codec:v mpeg2video -g 15 ^
-mbd rd -mbcmp satd -precmp satd -cmp satd -subcmp satd -b_strategy 2 ^
-vf scale=1024:-1:flags=lanczos,pad=1024:576:(ow-iw)/2:(oh-ih)/2,scale=720:576:flags=lanczos -r 25 ^
-b:v 5700k -maxrate 9000k -bufsize 1835008 ^
-packetsize 2048 -muxrate 10080000 -an -pass 1 -y out.mpg
..\ffmpeg -ss 00:47:00 -i %FILE% -to 00:02:00 ^
-codec:v mpeg2video -g 15 ^
-mbd rd -mbcmp satd -precmp satd -cmp satd -subcmp satd -b_strategy 2 ^
-vf scale=1024:-1:flags=lanczos,pad=1024:576:(ow-iw)/2:(oh-ih)/2,scale=720:576:flags=lanczos -r 25 ^
-b:v 5700k -maxrate 9000k -bufsize 1835008 ^
-packetsize 2048 -muxrate 10080000 -an -pass 2 -y out.mpg
..\ffmpeg -ss 00:47:00 -i %FILE% -to 00:02:00 ^
-codec:v mpeg2video -g 15 ^
-mbd rd -mbcmp satd -precmp satd -cmp satd -subcmp satd -b_strategy 2 ^
-vf scale=1024:-1:flags=lanczos,pad=1024:576:(ow-iw)/2:(oh-ih)/2,scale=720:576:flags=lanczos -r 25 ^
-b:v 5700k -maxrate 9000k -bufsize 1835008 ^
-packetsize 2048 -muxrate 10080000 -an -pass 1 -y out.mpg
..\ffmpeg -ss 00:47:00 -i %FILE% -to 00:02:00 ^
-codec:v mpeg2video -g 15 ^
-mbd rd -mbcmp satd -precmp satd -cmp satd -subcmp satd -b_strategy 2 ^
-vf scale=1024:-1:flags=lanczos,pad=1024:576:(ow-iw)/2:(oh-ih)/2,scale=720:576:flags=lanczos -r 25 ^
-b:v 5700k -maxrate 9000k -bufsize 1835008 ^
-packetsize 2048 -muxrate 10080000 -an -pass 2 -y out.mpg
>>2984007
нет, дефекты пленки действительно есть в оригинале, но в видео которое получается после кодирования явные дрожания квадратиков которых нет вообще в оригинале. на гифке это может не так заметно(и это еще не самый худший вариант видео получился).
нет, дефекты пленки действительно есть в оригинале, но в видео которое получается после кодирования явные дрожания квадратиков которых нет вообще в оригинале. на гифке это может не так заметно(и это еще не самый худший вариант видео получился).
>>2984011
Я тебе наперëд скажу, что есть две хитрых причины:
- частная - у модуля rdo в libavcodec с mpeg2 есть баг, проявляющийся при кое-каком сочетании настроек; я нашëл его давно, за детали не поясню, адекватного средства воспроизведения под рукой нет, чтобы в твоëм видео идентифицировать;
- общая - дрожание может быть следствием эффекта Гиббса при передискретизации ( scale).
Хорошо, что само видео дал. Попробую на работе завтра глянуть.
Я тебе наперëд скажу, что есть две хитрых причины:
- частная - у модуля rdo в libavcodec с mpeg2 есть баг, проявляющийся при кое-каком сочетании настроек; я нашëл его давно, за детали не поясню, адекватного средства воспроизведения под рукой нет, чтобы в твоëм видео идентифицировать;
- общая - дрожание может быть следствием эффекта Гиббса при передискретизации ( scale).
Хорошо, что само видео дал. Попробую на работе завтра глянуть.
>>2984005
Я посмотрел ролик. Криминала не вижу.
Давай оригинал и то, что получается в mpeg2. И найди какой-нибудь файлообменник годный.
Я посмотрел ролик. Криминала не вижу.
Давай оригинал и то, что получается в mpeg2. И найди какой-нибудь файлообменник годный.
объясните мне, тупому человеку, кое-что
я не понимаю базовых вещей.
вот если у меня есть скачанный ролик в кодеке H.264.
Я хочу его перекодировать другой кодек VVC или AV1. При перекодировке качество в любом случае упадёт, какие бы настройки я не выбрал? Простите за тупой вопрос - я правда не понимаю.
Как при перекодировке выбрать такие параметры, чтобы не потерять в качестве для нескольких файлов сразу?
Спасибо
я не понимаю базовых вещей.
вот если у меня есть скачанный ролик в кодеке H.264.
Я хочу его перекодировать другой кодек VVC или AV1. При перекодировке качество в любом случае упадёт, какие бы настройки я не выбрал? Простите за тупой вопрос - я правда не понимаю.
Как при перекодировке выбрать такие параметры, чтобы не потерять в качестве для нескольких файлов сразу?
Спасибо
>>2984722
Упадëт в любом случае. Так кодек задачу решает. Нет способа, например, даже дважды каскадно пожать через libx264, чтобы со второй пережатки потерь не было.
Упадëт в любом случае. Так кодек задачу решает. Нет способа, например, даже дважды каскадно пожать через libx264, чтобы со второй пережатки потерь не было.
>>2984722
Поговаривают, это ахуенный кодек, но без суперкомпьютера ты не сможешь кодировать в него.
>AV1
Поговаривают, это ахуенный кодек, но без суперкомпьютера ты не сможешь кодировать в него.
>>2984820
Когда-то в 2005-ом году на актуальном железе libx264 давал на SD+PAL около 5 кадров/с на умеренных настройках и с почти вдвое (на самом деле, в добрых 1,5 раза) меньшей шириной потока по сравнению с h.263 или ASP. Но тогда производительность x86 процессоров росла гораздо быстрее, чем сейчас. Сегодня на HD+NTSC у libx265 и прочих HEVC скорость кодирования тоже 5 кадров/с при эффективности сжатия едва ли превосходящей h.264 раза в полтора. А есть ещё более нагруженные по вычислениям AV1 и VVC.
Сегодня я бы сказал, что H.264 — это всерьёз и надолго. Медленное новое — это предмет для моего скепсиса.
Когда-то в 2005-ом году на актуальном железе libx264 давал на SD+PAL около 5 кадров/с на умеренных настройках и с почти вдвое (на самом деле, в добрых 1,5 раза) меньшей шириной потока по сравнению с h.263 или ASP. Но тогда производительность x86 процессоров росла гораздо быстрее, чем сейчас. Сегодня на HD+NTSC у libx265 и прочих HEVC скорость кодирования тоже 5 кадров/с при эффективности сжатия едва ли превосходящей h.264 раза в полтора. А есть ещё более нагруженные по вычислениям AV1 и VVC.
Сегодня я бы сказал, что H.264 — это всерьёз и надолго. Медленное новое — это предмет для моего скепсиса.
>>2984909
И снова нихуя информации. Что за железо? Какое качество, битрейт, пресет? Бля, процессор-то какой?
И снова нихуя информации. Что за железо? Какое качество, битрейт, пресет? Бля, процессор-то какой?
>>2984947
это всё так важно?
ну ладно
проц 8700, память(не знаю, надо нет) 32гб
разрешение 1920x1080
изначально было
File size : 1.61 GiB
Duration : 22 min 29 s
Overall bit rate : 10.3 Mb/s
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 3 Ref Frames
стало
File size : 961 MiB
Duration : 22 min 29 s
Overall bit rate : 5 971 kb/s
Format : AV1
Format/Info : AOMedia Video 1
Format profile : Main@L4.0
перекодировал через xmedia recode, так как с ffmpeg пока не сильно разобралс(какие там ключи нужны, какие нет): Quantizer 25; CPU-Used 12; Tile Columns 4; Tile Raws 4 - это параметры не записывал, поэтому мог не совсем точно вспомнить
это всё так важно?
ну ладно
проц 8700, память(не знаю, надо нет) 32гб
разрешение 1920x1080
изначально было
File size : 1.61 GiB
Duration : 22 min 29 s
Overall bit rate : 10.3 Mb/s
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 3 Ref Frames
стало
File size : 961 MiB
Duration : 22 min 29 s
Overall bit rate : 5 971 kb/s
Format : AV1
Format/Info : AOMedia Video 1
Format profile : Main@L4.0
перекодировал через xmedia recode, так как с ffmpeg пока не сильно разобралс(какие там ключи нужны, какие нет): Quantizer 25; CPU-Used 12; Tile Columns 4; Tile Raws 4 - это параметры не записывал, поэтому мог не совсем точно вспомнить
>>2984835
Только потому что хуй264 не обложен патентами. В идеале мы сейчас должны были все сидеть на хуй265 и облизываться на хуй266. А по факту остается только какой-то революции в отведении тепла ждать, чтобы инцеловская кукуруза в 100 ядер могла ебашить, а чем больше это откладывается, тем дольше займет дальнейший переход на более продвинутые форматы, ведь хуй264 сейчас разве что моя жопа не воспроизводит.
>>2984959
Читать как:
АВ1 победа.
>H.264 — это всерьёз и надолго
Только потому что хуй264 не обложен патентами. В идеале мы сейчас должны были все сидеть на хуй265 и облизываться на хуй266. А по факту остается только какой-то революции в отведении тепла ждать, чтобы инцеловская кукуруза в 100 ядер могла ебашить, а чем больше это откладывается, тем дольше займет дальнейший переход на более продвинутые форматы, ведь хуй264 сейчас разве что моя жопа не воспроизводит.
>>2984959
>CPU-Used 12; Tile Columns 4; Tile Raws 4
Читать как:
>я потратил 3 часа своей жизни, чтобы транскодировать в уебищном качестве 22 минуты
АВ1 победа.
>>2984960
Не понял про аб1
Не понял про аб1
>>2984259
чет ни разу файлообменниками не пользовался.
если в описании видео ffmpeg пишет yuv420p(tv, top first) это значит что видео интерлейсное?
чет ни разу файлообменниками не пользовался.
если в описании видео ffmpeg пишет yuv420p(tv, top first) это значит что видео интерлейсное?
>>2984960
Вообще-то тоже обложен и довольно густо.
Если бы производительность бытовых процессоров в расчëте на одно ядро росла также как в нулевых или хотя бы в начале десятых. Но по факту имеем то, что производительность одного ядра где-то с три годика назад упëрлась в потолок и растëт на жалкие единицы процентов. Облизываться даже на следующее поколение можно только во влажных снах. Оно уже сейчас непрактично.
Влажно, да.
>хуй264 не обложен патентами
Вообще-то тоже обложен и довольно густо.
> В идеале мы сейчас должны были все сидеть на хуй265 и облизываться на хуй266.
Если бы производительность бытовых процессоров в расчëте на одно ядро росла также как в нулевых или хотя бы в начале десятых. Но по факту имеем то, что производительность одного ядра где-то с три годика назад упëрлась в потолок и растëт на жалкие единицы процентов. Облизываться даже на следующее поколение можно только во влажных снах. Оно уже сейчас непрактично.
> А по факту остается только какой-то революции в отведении тепла ждать, чтобы инцеловская кукуруза в 100 ядер могла ебашить, а чем больше это откладывается
Влажно, да.
Помогите с youtube-dl, при прописывании
на некоторых видео высирается вместо ссылки на видеопоток ссылка на какой-то manifest.googlevideo.com/api/videpla... как вернуть на первое место видеопоток или заставить youtube-dl выдавать 3 ссылки?
>youtube-dl -g URL
на некоторых видео высирается вместо ссылки на видеопоток ссылка на какой-то manifest.googlevideo.com/api/videpla... как вернуть на первое место видеопоток или заставить youtube-dl выдавать 3 ссылки?
>>2985125
Пофиксил сам, нужно дополнительно прописывать
Т.е по итогу должно быть
Пофиксил сам, нужно дополнительно прописывать
>--youtube-skip-dash-manifest
Т.е по итогу должно быть
>youtube-dl -g --youtube-skip-dash-manifest URL
>>2981121
Тебе его обрезать надо наверное с помощью команду cropdetect и crop
Тебе его обрезать надо наверное с помощью команду cropdetect и crop
>>2982187
Нужно резать от ключевого кадра, через avidemux посмотри точное время или там подреж
Нужно резать от ключевого кадра, через avidemux посмотри точное время или там подреж
>>2985115
Десять лет как. Посмотри на сенди бриджи и иви средней руки, если ты вставишь вместо 2500k современное аналогичное говно9 1488К, ты не заметишь разницы в производительности. То же самое с видеокартами. Флагман 2011 года по производительности в играх чуть слабее "народного" говна в виде 1060, а этого уже достаточно для ебы. А с учетом уменьшения техпроцесса, а следовательно температуры, а следовательно износ вентиляторов будет нулевой большую часть рабочего времени (поскольку они не работают в простое), все эти 1060 будут актуальны еще 10-15 лет.
>с три годика назад
Десять лет как. Посмотри на сенди бриджи и иви средней руки, если ты вставишь вместо 2500k современное аналогичное говно9 1488К, ты не заметишь разницы в производительности. То же самое с видеокартами. Флагман 2011 года по производительности в играх чуть слабее "народного" говна в виде 1060, а этого уже достаточно для ебы. А с учетом уменьшения техпроцесса, а следовательно температуры, а следовательно износ вентиляторов будет нулевой большую часть рабочего времени (поскольку они не работают в простое), все эти 1060 будут актуальны еще 10-15 лет.
>>2985214
Хуя дебил
2500 отсасывает современному двухядерному пентиуму
> Посмотри на сенди бриджи и иви средней руки, если ты вставишь вместо 2500k современное аналогичное говно9 1488К, ты не заметишь разницы в производительности
Хуя дебил
2500 отсасывает современному двухядерному пентиуму
>>2985263
В тестах количества попугаев? Одноядерная скорость какого-нибудь говно7 4770 и говно7 9700 всего лишь 25%, а промежуток выхода около 7 лет. В обычной работе, то есть игры/веб, это разница между говном и мочой.
В тестах количества попугаев? Одноядерная скорость какого-нибудь говно7 4770 и говно7 9700 всего лишь 25%, а промежуток выхода около 7 лет. В обычной работе, то есть игры/веб, это разница между говном и мочой.
ffmpeg вообще умеет резать по ключевым кадрам?
Если резануть вебмку так, без перекодирования: ffmpeg -ss 00:56.248 -to 01:33.274 -i input.webm -c copy out.webm То на выходе мы получаем рассинхрон звука с видео.
Тот же mkvtoolnix режет неточно, зато без рассинхрона, что меня вполне устраивает.
Если резануть вебмку так, без перекодирования: ffmpeg -ss 00:56.248 -to 01:33.274 -i input.webm -c copy out.webm То на выходе мы получаем рассинхрон звука с видео.
Тот же mkvtoolnix режет неточно, зато без рассинхрона, что меня вполне устраивает.
>>2986566
Любой файл так режет.
Любой файл так режет.
>>2986565
libvpx-ссань по дефолту ставить g 9999 по какой-то неведомой причине с самого своего появления. Так что лучше исходники режь.
>webm
libvpx-ссань по дефолту ставить g 9999 по какой-то неведомой причине с самого своего появления. Так что лучше исходники режь.
>>2986565
-avoid_negative_ts 1? или как там?
-avoid_negative_ts 1? или как там?
>>2987008
Преобразует 24 полных кадра в 60 полей, чтобы кино показывать по телевизору системы NTSC. Это такой ugly hack уровня /tv/.
Преобразует 24 полных кадра в 60 полей, чтобы кино показывать по телевизору системы NTSC. Это такой ugly hack уровня /tv/.
не знаю, где спросить, спрошу тут
ищу ses2sesx софтину, нашёл только один на варезнике старый варик, вирустотал говорит там салти
мне нужен именно ses2sesx, НЕ sesх2sesx
не в видеомонтаж тред же идтить
ищу ses2sesx софтину, нашёл только один на варезнике старый варик, вирустотал говорит там салти
мне нужен именно ses2sesx, НЕ sesх2sesx
не в видеомонтаж тред же идтить
тут наверняка сидят разбирающиеся в видеопрограммах люди. подскажите простой сплиттер видосов. без пердоленья с консолью и перерендеринга с нуля как в сони вегасе и прочих. желательно чтобы чисто указать начало куска, конец куска, жмакнуть "вырезать" - и программа тупо вырежет из видеофайла кусок, дорендерив часть вначале и часть в конце.
есть вообще такие или это недостижимая технология будущего?
есть вообще такие или это недостижимая технология будущего?
я помню у меня даже был уже вроде какой-то сплиттер, но он на больших видосах постоянно крашился и уже пришлось удалить, и если был большой битрейт то он зависал намертво.
может есть какая-то простая обёртка для ffmpeg которая делает то же самое не зависая и не крашась?
может есть какая-то простая обёртка для ffmpeg которая делает то же самое не зависая и не крашась?
>>2987567
virtualdubmod
virtualdubmod
>>2987554
А на ntsc dvd как хранится видео? Закодировал видео также как и для pal, только изменив частоту на 29.97 и размер изображения, и sony dvd architect нормально воспринимает такое видео для ntsc dvd, т.е. видео может храниться закодированное прогрессивными кадрами, а откуда тогда будут браться чересстрочные поля?
В результате pulldown-а кадры всегда преобразуются в поля? А если я хочу pal dvd сделать то что тогда?
А на ntsc dvd как хранится видео? Закодировал видео также как и для pal, только изменив частоту на 29.97 и размер изображения, и sony dvd architect нормально воспринимает такое видео для ntsc dvd, т.е. видео может храниться закодированное прогрессивными кадрами, а откуда тогда будут браться чересстрочные поля?
В результате pulldown-а кадры всегда преобразуются в поля? А если я хочу pal dvd сделать то что тогда?
>>2987700
во, именно так я себе представлял идеальный сплиттер. спасибо анон.
во, именно так я себе представлял идеальный сплиттер. спасибо анон.
А с помощью youtube-dl возможно скачивать тиктоки и инстаграмы? Ато у меня получается только ютуб.
>>2988389
Инстаграм gallery-dl
Тикток YouTube dl качает, но с водяным знаком. Лучше через сайт https://ssstik.io/ru/
Инстаграм gallery-dl
Тикток YouTube dl качает, но с водяным знаком. Лучше через сайт https://ssstik.io/ru/
>>2988498
А качество вроде не ухудшилось
А качество вроде не ухудшилось
Так, нужно перекодировать видео по этим параметрам:
1080p60fps.
Контейнер — mp4.
Аудиокодек — AAC-LC, 48 кГц, стерео, битрейт до 384 кбит/сек.
Видеокодек — H.264, прогрессивная развертка, высокий профиль, два последовательных B-кадра, GOP равняется половинной частоте кадров, CABAC, переменный битрейт (до 24 мбит/сек), цветовая субдискретизация 4:2:0, цветовое пространство BT.709 (значение H.273: 1).
1080p60fps.
Контейнер — mp4.
Аудиокодек — AAC-LC, 48 кГц, стерео, битрейт до 384 кбит/сек.
Видеокодек — H.264, прогрессивная развертка, высокий профиль, два последовательных B-кадра, GOP равняется половинной частоте кадров, CABAC, переменный битрейт (до 24 мбит/сек), цветовая субдискретизация 4:2:0, цветовое пространство BT.709 (значение H.273: 1).
>>2989521
Тогда в чём претензии? Берёшь и перекодируешь. Я вот пользуюсь гуём в лице Axiom и мозг себе не забиваю всякой хуйнёй. Ну, не считая забивания мозга кодеками-хуёдеками, но это уже само собой разумеется.
Тогда в чём претензии? Берёшь и перекодируешь. Я вот пользуюсь гуём в лице Axiom и мозг себе не забиваю всякой хуйнёй. Ну, не считая забивания мозга кодеками-хуёдеками, но это уже само собой разумеется.
>>2989459
ffmpeg -i video.mp4 -c:v libx264 -profile high -pix_fmt yuv420p -vf scale=1920x1080,setsar=1:1,fps=60 -c:a aac -b:a 256k -ar 48000 out.mp4
ffmpeg -i video.mp4 -c:v libx264 -profile high -pix_fmt yuv420p -vf scale=1920x1080,setsar=1:1,fps=60 -c:a aac -b:a 256k -ar 48000 out.mp4
>>2989567
-b:v 22000k
-b:v 22000k
>>2987746
В пределах каждой gop для mpeg-es можно для ntsc определить поток как видео на 60 полей или как фильм на 24 кадра с pulldown-флагами, определяющими способ сборки 60 полей из 24 кадров (есть варианты). В последнем случае в потоке кодированы полные кадры (с построчной развëрткой), а телекино должно делаться на стороне воспроизводящего устройства. В пределах одного потока mpeg-ps или mpeg-ts (на основе которого сделаны vob) можно такие фрагменты чередовать: например, есть у тебя документальная картина, где чередуются сцены снятые на видео (интервью режиссëра), развëртка в которых чересстрочная, и сцены из фильма, которые из скана киноленты с построчной развëрткой и pulldown-флагами. Технически приведëнный пример осуществить сложно, поэтому, зачастую в таком материале телекино делается ещë при монтаже, а материал кодируется как чересстрочный ntsc. Любители переменной частоты кадров иногда декодированный с таких dvd материал разбивают на сцены и применяют по месту либо фильтр преобразования развëртки, либо обратного телекино.
>>2987746
То, что исходный материал был построчный на 30 кадров, ещë не значит, что mpeg2-кодер не закодировал его как 60 полей. НЯП, у mpeg2 (стандартом h.262, можешь почитать ради интереса, текст должен быть доступен чуть ли не прямо на сайте ITU) не предусмотрено режима кодирования построчного изображения для ntsc. Если ты материал уже закодировал, то можно глянуть отчëт mediainfo о файле с mpeg-es или mpeg-ts - в отчëте должен быть указат тип развëртки. Наперëд скажу, что для чересстрочного материала у mpeg2 есть кое-какие особенности представления изображения и поиска движения.
Вполне возможно. Тут тебе или стандарт глядеть, чтобы получить исчерпывающую информацию, или только отчëт mediainfo, чтобы разобаться в своëм результате.
>>2987746
Для pal точно помню, что стандартом предусмотрено представление построчного изображения, как и чересстрочного. Если материал построчеый, то не забывай об этом программе кодирования сообщить. Если материал чересстрочный, то не забывай той же программе кодирования правильно сообщить, какое поле первое. И то и другое важно, т.к. влияет на алгоритм поиска движения.
> А на ntsc dvd как хранится видео?
В пределах каждой gop для mpeg-es можно для ntsc определить поток как видео на 60 полей или как фильм на 24 кадра с pulldown-флагами, определяющими способ сборки 60 полей из 24 кадров (есть варианты). В последнем случае в потоке кодированы полные кадры (с построчной развëрткой), а телекино должно делаться на стороне воспроизводящего устройства. В пределах одного потока mpeg-ps или mpeg-ts (на основе которого сделаны vob) можно такие фрагменты чередовать: например, есть у тебя документальная картина, где чередуются сцены снятые на видео (интервью режиссëра), развëртка в которых чересстрочная, и сцены из фильма, которые из скана киноленты с построчной развëрткой и pulldown-флагами. Технически приведëнный пример осуществить сложно, поэтому, зачастую в таком материале телекино делается ещë при монтаже, а материал кодируется как чересстрочный ntsc. Любители переменной частоты кадров иногда декодированный с таких dvd материал разбивают на сцены и применяют по месту либо фильтр преобразования развëртки, либо обратного телекино.
>>2987746
>т.е. видео может храниться закодированное прогрессивными кадрами, а откуда тогда будут браться чересстрочные поля?
То, что исходный материал был построчный на 30 кадров, ещë не значит, что mpeg2-кодер не закодировал его как 60 полей. НЯП, у mpeg2 (стандартом h.262, можешь почитать ради интереса, текст должен быть доступен чуть ли не прямо на сайте ITU) не предусмотрено режима кодирования построчного изображения для ntsc. Если ты материал уже закодировал, то можно глянуть отчëт mediainfo о файле с mpeg-es или mpeg-ts - в отчëте должен быть указат тип развëртки. Наперëд скажу, что для чересстрочного материала у mpeg2 есть кое-какие особенности представления изображения и поиска движения.
> В результате pulldown-а кадры всегда преобразуются в поля?
Вполне возможно. Тут тебе или стандарт глядеть, чтобы получить исчерпывающую информацию, или только отчëт mediainfo, чтобы разобаться в своëм результате.
>>2987746
>А если я хочу pal dvd сделать то что тогда?
Для pal точно помню, что стандартом предусмотрено представление построчного изображения, как и чересстрочного. Если материал построчеый, то не забывай об этом программе кодирования сообщить. Если материал чересстрочный, то не забывай той же программе кодирования правильно сообщить, какое поле первое. И то и другое важно, т.к. влияет на алгоритм поиска движения.
>>2987746
В пределах каждой gop для mpeg-es можно для ntsc определить поток как видео на 60 полей или как фильм на 24 кадра с pulldown-флагами, определяющими способ сборки 60 полей из 24 кадров (есть варианты). В последнем случае в потоке кодированы полные кадры (с построчной развëрткой), а телекино должно делаться на стороне воспроизводящего устройства. В пределах одного потока mpeg-ps или mpeg-ts (на основе которого сделаны vob) можно такие фрагменты чередовать: например, есть у тебя документальная картина, где чередуются сцены снятые на видео (интервью режиссëра), развëртка в которых чересстрочная, и сцены из фильма, которые из скана киноленты с построчной развëрткой и pulldown-флагами. Технически приведëнный пример осуществить сложно, поэтому, зачастую в таком материале телекино делается ещë при монтаже, а материал кодируется как чересстрочный ntsc. Любители переменной частоты кадров иногда декодированный с таких dvd материал разбивают на сцены и применяют по месту либо фильтр преобразования развëртки, либо обратного телекино.
>>2987746
То, что исходный материал был построчный на 30 кадров, ещë не значит, что mpeg2-кодер не закодировал его как 60 полей. НЯП, у mpeg2 (стандартом h.262, можешь почитать ради интереса, текст должен быть доступен чуть ли не прямо на сайте ITU) не предусмотрено режима кодирования построчного изображения для ntsc. Если ты материал уже закодировал, то можно глянуть отчëт mediainfo о файле с mpeg-es или mpeg-ts - в отчëте должен быть указат тип развëртки. Наперëд скажу, что для чересстрочного материала у mpeg2 есть кое-какие особенности представления изображения и поиска движения.
Вполне возможно. Тут тебе или стандарт глядеть, чтобы получить исчерпывающую информацию, или только отчëт mediainfo, чтобы разобаться в своëм результате.
>>2987746
Для pal точно помню, что стандартом предусмотрено представление построчного изображения, как и чересстрочного. Если материал построчеый, то не забывай об этом программе кодирования сообщить. Если материал чересстрочный, то не забывай той же программе кодирования правильно сообщить, какое поле первое. И то и другое важно, т.к. влияет на алгоритм поиска движения.
> А на ntsc dvd как хранится видео?
В пределах каждой gop для mpeg-es можно для ntsc определить поток как видео на 60 полей или как фильм на 24 кадра с pulldown-флагами, определяющими способ сборки 60 полей из 24 кадров (есть варианты). В последнем случае в потоке кодированы полные кадры (с построчной развëрткой), а телекино должно делаться на стороне воспроизводящего устройства. В пределах одного потока mpeg-ps или mpeg-ts (на основе которого сделаны vob) можно такие фрагменты чередовать: например, есть у тебя документальная картина, где чередуются сцены снятые на видео (интервью режиссëра), развëртка в которых чересстрочная, и сцены из фильма, которые из скана киноленты с построчной развëрткой и pulldown-флагами. Технически приведëнный пример осуществить сложно, поэтому, зачастую в таком материале телекино делается ещë при монтаже, а материал кодируется как чересстрочный ntsc. Любители переменной частоты кадров иногда декодированный с таких dvd материал разбивают на сцены и применяют по месту либо фильтр преобразования развëртки, либо обратного телекино.
>>2987746
>т.е. видео может храниться закодированное прогрессивными кадрами, а откуда тогда будут браться чересстрочные поля?
То, что исходный материал был построчный на 30 кадров, ещë не значит, что mpeg2-кодер не закодировал его как 60 полей. НЯП, у mpeg2 (стандартом h.262, можешь почитать ради интереса, текст должен быть доступен чуть ли не прямо на сайте ITU) не предусмотрено режима кодирования построчного изображения для ntsc. Если ты материал уже закодировал, то можно глянуть отчëт mediainfo о файле с mpeg-es или mpeg-ts - в отчëте должен быть указат тип развëртки. Наперëд скажу, что для чересстрочного материала у mpeg2 есть кое-какие особенности представления изображения и поиска движения.
> В результате pulldown-а кадры всегда преобразуются в поля?
Вполне возможно. Тут тебе или стандарт глядеть, чтобы получить исчерпывающую информацию, или только отчëт mediainfo, чтобы разобаться в своëм результате.
>>2987746
>А если я хочу pal dvd сделать то что тогда?
Для pal точно помню, что стандартом предусмотрено представление построчного изображения, как и чересстрочного. Если материал построчеый, то не забывай об этом программе кодирования сообщить. Если материал чересстрочный, то не забывай той же программе кодирования правильно сообщить, какое поле первое. И то и другое важно, т.к. влияет на алгоритм поиска движения.
>>2989577
вот например пробовал закодировать ntsc видео для dvd, частоту кадров при кодировании оставил неизменной, потом файл прогнал через dgpulldown.
из mediainfo:
Frame rate : 23.976 (24000/1001) FPS
Scan type : Progressive
Scan order : 2:3 Pulldown
>>2989577
тут нет противоречия?
>>2989577
Как?
А ну и расширение файла как нибудь влияет на результат? Если ставить m2v, ts? Сейчас ставлю mpg.
вот например пробовал закодировать ntsc видео для dvd, частоту кадров при кодировании оставил неизменной, потом файл прогнал через dgpulldown.
из mediainfo:
Frame rate : 23.976 (24000/1001) FPS
Scan type : Progressive
Scan order : 2:3 Pulldown
>>2989577
>для ntsc определить поток как видео на 60 полей или как фильм на 24 кадра с pulldown-флагами
>у mpeg2 не предусмотрено режима кодирования построчного изображения для ntsc
тут нет противоречия?
>>2989577
>Если материал построчеый, то не забывай об этом программе кодирования сообщить.
Как?
А ну и расширение файла как нибудь влияет на результат? Если ставить m2v, ts? Сейчас ставлю mpg.
7 Кб, 306x157Какой профайл выбирать, main или main10? Какой режим скалирования для даунскейла из 4к? Какой битрейт оптимальный для размера+максимального качества? Почему constant quality такая параша?
>>2989890
Я дам неожиданную рекомендацию. Bilinear spline.
Между ФНЧ при передискретизации есть следующая разница.
Наименьшие искажения даёт гауссовский фильтр из-за того, что гауссовская функция является собственной функцией преобразования Фурье; наименьшие искажения достигаются при большом размере окна, т.к. гауссовская функция не финитная, на практике из соображения производительности выбирают окно из 32...64 отсчётов, что даёт СКО за счёт эффекта Гиббса в районе -40 дБ; плюс при малой ширине лепестка (для более чёткой картинки) на изображении вблизи границы между статичной текстурой и резким краем другого объекта будут заметны изкажения, воспринимаемые как шум; требуется внимательный подбор пареметра ширины лепестка и, если предоставляется, ширины окна. Фильтр почти не обогощает спектр и не даёт переколебаний вблизи резких колебаний яркости.
>Какой режим скалирования для даунскейла из 4к?
Я дам неожиданную рекомендацию. Bilinear spline.
Между ФНЧ при передискретизации есть следующая разница.
Наименьшие искажения даёт гауссовский фильтр из-за того, что гауссовская функция является собственной функцией преобразования Фурье; наименьшие искажения достигаются при большом размере окна, т.к. гауссовская функция не финитная, на практике из соображения производительности выбирают окно из 32...64 отсчётов, что даёт СКО за счёт эффекта Гиббса в районе -40 дБ; плюс при малой ширине лепестка (для более чёткой картинки) на изображении вблизи границы между статичной текстурой и резким краем другого объекта будут заметны изкажения, воспринимаемые как шум; требуется внимательный подбор пареметра ширины лепестка и, если предоставляется, ширины окна. Фильтр почти не обогощает спектр и не даёт переколебаний вблизи резких колебаний яркости.
>>2989949
Способ интерполяции по ближайшему смежному отсчёту - это такой сверхбыстрый способ передискретизации. Затычка. Очень сильно обогощает спектр сигнала и добавляет в пространственной области заметные искажения. При подготовке материаорв использовать смысла нет.
Билинейная фильтрация. Быстрый способ интерполяции. Имеет смысл только при повышении частоты дискретизации. Обогащает спектр сигнала чуть меньше, чем метод по ближайшему смежному, и пространственных исаажений вносит сильно меньше. Оптимум в смысле СКО, насколько я помню, достигается при кратном изменении частоты дискретизации. Последнее не имеет смысла в большинстве приктических задач подготовки изображений. Тоже фильтр-затычка, когда вычислительная производительность любой ценой.
Способ интерполяции по ближайшему смежному отсчёту - это такой сверхбыстрый способ передискретизации. Затычка. Очень сильно обогощает спектр сигнала и добавляет в пространственной области заметные искажения. При подготовке материаорв использовать смысла нет.
Билинейная фильтрация. Быстрый способ интерполяции. Имеет смысл только при повышении частоты дискретизации. Обогащает спектр сигнала чуть меньше, чем метод по ближайшему смежному, и пространственных исаажений вносит сильно меньше. Оптимум в смысле СКО, насколько я помню, достигается при кратном изменении частоты дискретизации. Последнее не имеет смысла в большинстве приктических задач подготовки изображений. Тоже фильтр-затычка, когда вычислительная производительность любой ценой.
>>2989950
А ты как хотел? Мы так-то сложную хуйню обсуждаем, в которой матана до страшной страсти. И это мы пока ещё в евклидовых гилбертовых пространствах и с теоремой Котельникова-Найквиста-Шеннона, а могли бы начать с другой теоремы отсчётов, например, с Хургина-Яковлева, а закончить более физически корректным пространством Соболева.
Тем более, я и практические рекомендации всё-таки привожу.
А ты как хотел? Мы так-то сложную хуйню обсуждаем, в которой матана до страшной страсти. И это мы пока ещё в евклидовых гилбертовых пространствах и с теоремой Котельникова-Найквиста-Шеннона, а могли бы начать с другой теоремы отсчётов, например, с Хургина-Яковлева, а закончить более физически корректным пространством Соболева.
Тем более, я и практические рекомендации всё-таки привожу.
>>2989957
Бикубическая интерполяция - это достаточно быстрый способ, компромисс между высокой вычислительной производительностью (раза в полтора ниже, чем у билинейной) и неплохим приближением в смысле СКО (лучше, чем у билинейной). Уже не затычка, но условия оптимального применения те же, что у билинкйной - кратное повышение частоты дискретизации. При понижении частоты дискретизации, особенно при отношении частот, близком к единице (например, 1,2...1,5), из-за наложения спектров и наложения сигналов смежных окон, даёт сильные пространственные искажения. В реальной практике используется при сверхбыстрой обработке изображений (например, при демонстрации эффектов в графических редакторах). При подготовке материалов использовать нецелесообразно.
Вариант с бикубической интерполяцией по яркостной составляющкй и билинейрой по цветоразеостной - чуть быстрее, чем простой бикубический, за счёт роста искажений в цветоразностных составляющих изображения. Червеческое зрение более терпимо к искажениям в цветоразностных составляющих.
Бикубическая интерполяция - это достаточно быстрый способ, компромисс между высокой вычислительной производительностью (раза в полтора ниже, чем у билинейной) и неплохим приближением в смысле СКО (лучше, чем у билинейной). Уже не затычка, но условия оптимального применения те же, что у билинкйной - кратное повышение частоты дискретизации. При понижении частоты дискретизации, особенно при отношении частот, близком к единице (например, 1,2...1,5), из-за наложения спектров и наложения сигналов смежных окон, даёт сильные пространственные искажения. В реальной практике используется при сверхбыстрой обработке изображений (например, при демонстрации эффектов в графических редакторах). При подготовке материалов использовать нецелесообразно.
Вариант с бикубической интерполяцией по яркостной составляющкй и билинейрой по цветоразеостной - чуть быстрее, чем простой бикубический, за счёт роста искажений в цветоразностных составляющих изображения. Червеческое зрение более терпимо к искажениям в цветоразностных составляющих.
>>2989975
Мне интересно, уйди со своим мраком негатива.
Мне интересно, уйди со своим мраком негатива.
>>2989967
Бикубический сплайн - это финитная поверхность, приближающая исходный сигнал в нескольких смежных окнах многочленами (в каждом окне определён многочлен третьей степени, как правило согласованный с многочленом в смежном окне через естественные граничные условия - равенство первой и второй производных в граничной точке). Это существенно более затратный способ интерполяции по сравнению с бикубическим, и даже по сравнению с фильтром Ланцоша. На практике имеет существенно меньшие искажения по сравнению с бикубической интерполяцией и существенно меньшие переколебания по сравнению с фильтром Ланцоша. Дополнительным преимуществом является устойчиврсть при отношении частот дискретизации в диапазоне 1...1,5 - искажения при высоком порядке фильтра (64 точки, например) дают существенно меньшие искажения по сравнению с фильтром Ланцоша при той же воспринимаемой резкозти.
Бикубический сплайн - это финитная поверхность, приближающая исходный сигнал в нескольких смежных окнах многочленами (в каждом окне определён многочлен третьей степени, как правило согласованный с многочленом в смежном окне через естественные граничные условия - равенство первой и второй производных в граничной точке). Это существенно более затратный способ интерполяции по сравнению с бикубическим, и даже по сравнению с фильтром Ланцоша. На практике имеет существенно меньшие искажения по сравнению с бикубической интерполяцией и существенно меньшие переколебания по сравнению с фильтром Ланцоша. Дополнительным преимуществом является устойчиврсть при отношении частот дискретизации в диапазоне 1...1,5 - искажения при высоком порядке фильтра (64 точки, например) дают существенно меньшие искажения по сравнению с фильтром Ланцоша при той же воспринимаемой резкозти.
>>2989949
fix.
>>2989980
Про area сходу не расскажу - нужно разбираться.
Фильтры Ланцоша и sinc являются родственниками. Фильтр sinc представляет собой окно отсчётов функции sin(x)/x, ширина которого определяется через отношения частоты дискретизации и частоты среза АЧХ фильтра. У бесконечно длинной последовательности sin(x)/x АЧХ является прямоугольной и содержит единственный лепесток вокруг нулевой частоты; у окна спектр сразу становится периодическим, что увеличивает искажения, связанные с наложением спектров исходного сигнала и окна; плюс спады АЧХ становятся не вертикальными, а пологими, что на практике приводит к необходимости сузить основной лепесток АЧХ. Последнее приводит к эффекту переколебания яркости вблизи резких границ на итоговом изображении. Фильтр вычислительно производительнее, чем бикубический сплайн, такой же по производительности, как Ланцоша, и уступает в разы билинейному.
Фильтр Ланцоша использует более хитрое окно. Расскажу чуть позже.
>Bicubic spline.
fix.
>>2989980
Про area сходу не расскажу - нужно разбираться.
Фильтры Ланцоша и sinc являются родственниками. Фильтр sinc представляет собой окно отсчётов функции sin(x)/x, ширина которого определяется через отношения частоты дискретизации и частоты среза АЧХ фильтра. У бесконечно длинной последовательности sin(x)/x АЧХ является прямоугольной и содержит единственный лепесток вокруг нулевой частоты; у окна спектр сразу становится периодическим, что увеличивает искажения, связанные с наложением спектров исходного сигнала и окна; плюс спады АЧХ становятся не вертикальными, а пологими, что на практике приводит к необходимости сузить основной лепесток АЧХ. Последнее приводит к эффекту переколебания яркости вблизи резких границ на итоговом изображении. Фильтр вычислительно производительнее, чем бикубический сплайн, такой же по производительности, как Ланцоша, и уступает в разы билинейному.
Фильтр Ланцоша использует более хитрое окно. Расскажу чуть позже.
>>2989998
На всякий случай поясню, что способы интерполяции, основанные на полиномиальных приближениях (>>2989957>>2989967>>2989980) на бытовом уровне можно представить как способы провести на координатной плоскости через последовательность точек контур из отрезков линий или полиномиальных кривых, а затем на полученных контурах отметить новые точки, соответствующие новой частоте дискретизации.
Способы интерполяции, основанные на свëртке с окном (основным финитным участком импульсной характеристики) какого-нибудь фильтра (гауссова, фильтра Ланцоша, фильтров Слепиана, прямоугольного и т.д.) можно представить себе следующим образом. Допустим, есть в виде кривой некоторый симметричный (относительно вертикальной оси координатной плоскости) колебательный процесс, интенсивность которого быстро убывает по мере удаления от начала координат. Теперь представь точки, расположенные равномерно вдоль горизонтальной, и отстоящие от горизонтальной оси на всякие разные расстояния. Измеряешь эти расстояния, это будут интенсивности отсчëтов исходного сигнала. Дальше масштабируешь упомянутый ранее колебательный процесс в соответствии с интенсивностью каждого отсчëта и перемещаешь увеличенную копию процесса горизонтально из начала координат к координате соответствующего отсчëта. Получилась целая куча накладывающихся друг на друга кривых. Дальше строишь вертикальные прямые, соответствующие новой частоте дискретизации, для каждой из которых находишь точки пересечения с кривыми и алгебраически суммируешь все отклонения точек пересечения от горизонтальной оси (суперпозиция). Вот это суть операции свëртки. Как нетрудно догадаться, окно фильтра можно построить по известным параметрам со сколь угодно высокой частотой дискретизации и сколь угодно большой длины. Вот по этому для такого способа интерполяции соотношения частот дискретизации ограничены только допустимыми искажениями финитности (эффектом Гиббса) и допустимыми искажениями при наложении спектров.
Теперь о том, Что касается фильтра с прямоугольной АЧХ; он же sinc, т.к. обратное преобразование Фурье от прямоугольного спектра - это функция sin(t)/t. Свëртка его импульсной характеристики с исходным дискретным сигналом - это практически лобовое решение восстановительной задачи теоремы Котельникова (т.е. восстановления по дискретным отсчëтам исходного непрерывного сигнала с финитным спектром и ограниченной энергией). Далее в большом алгоритме интерполяции остаëтся только повторно дискретизировать восстановленную модель непрерывного сигнала уже с целевой частотой дискретизации.
Чем отличаются прямоугольный фильтр и фильтр Ланцоша? Окно фильтра Ланцоша состоит из поотсчëтного произвндения двух окон прямоугольных фильтров с разной частотой среза (и, соответственно, разной шириной основного лепестка). Дополнительно отсчëты, близкие к краям окна сделаны нулевыми. Фильтр Ланцоша является улучшением sinc-фильтра, которое при незначительном снижении резкости (за счëт относительного расширенич основного лепестка) значительно снижает переколебания и эффект от наложения смежных окон (за счëт подавления колебательного процесса вблизи краëв окна).
На всякий случай поясню, что способы интерполяции, основанные на полиномиальных приближениях (>>2989957>>2989967>>2989980) на бытовом уровне можно представить как способы провести на координатной плоскости через последовательность точек контур из отрезков линий или полиномиальных кривых, а затем на полученных контурах отметить новые точки, соответствующие новой частоте дискретизации.
Способы интерполяции, основанные на свëртке с окном (основным финитным участком импульсной характеристики) какого-нибудь фильтра (гауссова, фильтра Ланцоша, фильтров Слепиана, прямоугольного и т.д.) можно представить себе следующим образом. Допустим, есть в виде кривой некоторый симметричный (относительно вертикальной оси координатной плоскости) колебательный процесс, интенсивность которого быстро убывает по мере удаления от начала координат. Теперь представь точки, расположенные равномерно вдоль горизонтальной, и отстоящие от горизонтальной оси на всякие разные расстояния. Измеряешь эти расстояния, это будут интенсивности отсчëтов исходного сигнала. Дальше масштабируешь упомянутый ранее колебательный процесс в соответствии с интенсивностью каждого отсчëта и перемещаешь увеличенную копию процесса горизонтально из начала координат к координате соответствующего отсчëта. Получилась целая куча накладывающихся друг на друга кривых. Дальше строишь вертикальные прямые, соответствующие новой частоте дискретизации, для каждой из которых находишь точки пересечения с кривыми и алгебраически суммируешь все отклонения точек пересечения от горизонтальной оси (суперпозиция). Вот это суть операции свëртки. Как нетрудно догадаться, окно фильтра можно построить по известным параметрам со сколь угодно высокой частотой дискретизации и сколь угодно большой длины. Вот по этому для такого способа интерполяции соотношения частот дискретизации ограничены только допустимыми искажениями финитности (эффектом Гиббса) и допустимыми искажениями при наложении спектров.
Теперь о том, Что касается фильтра с прямоугольной АЧХ; он же sinc, т.к. обратное преобразование Фурье от прямоугольного спектра - это функция sin(t)/t. Свëртка его импульсной характеристики с исходным дискретным сигналом - это практически лобовое решение восстановительной задачи теоремы Котельникова (т.е. восстановления по дискретным отсчëтам исходного непрерывного сигнала с финитным спектром и ограниченной энергией). Далее в большом алгоритме интерполяции остаëтся только повторно дискретизировать восстановленную модель непрерывного сигнала уже с целевой частотой дискретизации.
Чем отличаются прямоугольный фильтр и фильтр Ланцоша? Окно фильтра Ланцоша состоит из поотсчëтного произвндения двух окон прямоугольных фильтров с разной частотой среза (и, соответственно, разной шириной основного лепестка). Дополнительно отсчëты, близкие к краям окна сделаны нулевыми. Фильтр Ланцоша является улучшением sinc-фильтра, которое при незначительном снижении резкости (за счëт относительного расширенич основного лепестка) значительно снижает переколебания и эффект от наложения смежных окон (за счëт подавления колебательного процесса вблизи краëв окна).
>>2989998
На всякий случай поясню, что способы интерполяции, основанные на полиномиальных приближениях (>>2989957>>2989967>>2989980) на бытовом уровне можно представить как способы провести на координатной плоскости через последовательность точек контур из отрезков линий или полиномиальных кривых, а затем на полученных контурах отметить новые точки, соответствующие новой частоте дискретизации.
Способы интерполяции, основанные на свëртке с окном (основным финитным участком импульсной характеристики) какого-нибудь фильтра (гауссова, фильтра Ланцоша, фильтров Слепиана, прямоугольного и т.д.) можно представить себе следующим образом. Допустим, есть в виде кривой некоторый симметричный (относительно вертикальной оси координатной плоскости) колебательный процесс, интенсивность которого быстро убывает по мере удаления от начала координат. Теперь представь точки, расположенные равномерно вдоль горизонтальной, и отстоящие от горизонтальной оси на всякие разные расстояния. Измеряешь эти расстояния, это будут интенсивности отсчëтов исходного сигнала. Дальше масштабируешь упомянутый ранее колебательный процесс в соответствии с интенсивностью каждого отсчëта и перемещаешь увеличенную копию процесса горизонтально из начала координат к координате соответствующего отсчëта. Получилась целая куча накладывающихся друг на друга кривых. Дальше строишь вертикальные прямые, соответствующие новой частоте дискретизации, для каждой из которых находишь точки пересечения с кривыми и алгебраически суммируешь все отклонения точек пересечения от горизонтальной оси (суперпозиция). Вот это суть операции свëртки. Как нетрудно догадаться, окно фильтра можно построить по известным параметрам со сколь угодно высокой частотой дискретизации и сколь угодно большой длины. Вот по этому для такого способа интерполяции соотношения частот дискретизации ограничены только допустимыми искажениями финитности (эффектом Гиббса) и допустимыми искажениями при наложении спектров.
Теперь о том, Что касается фильтра с прямоугольной АЧХ; он же sinc, т.к. обратное преобразование Фурье от прямоугольного спектра - это функция sin(t)/t. Свëртка его импульсной характеристики с исходным дискретным сигналом - это практически лобовое решение восстановительной задачи теоремы Котельникова (т.е. восстановления по дискретным отсчëтам исходного непрерывного сигнала с финитным спектром и ограниченной энергией). Далее в большом алгоритме интерполяции остаëтся только повторно дискретизировать восстановленную модель непрерывного сигнала уже с целевой частотой дискретизации.
Чем отличаются прямоугольный фильтр и фильтр Ланцоша? Окно фильтра Ланцоша состоит из поотсчëтного произвндения двух окон прямоугольных фильтров с разной частотой среза (и, соответственно, разной шириной основного лепестка). Дополнительно отсчëты, близкие к краям окна сделаны нулевыми. Фильтр Ланцоша является улучшением sinc-фильтра, которое при незначительном снижении резкости (за счëт относительного расширенич основного лепестка) значительно снижает переколебания и эффект от наложения смежных окон (за счëт подавления колебательного процесса вблизи краëв окна).
На всякий случай поясню, что способы интерполяции, основанные на полиномиальных приближениях (>>2989957>>2989967>>2989980) на бытовом уровне можно представить как способы провести на координатной плоскости через последовательность точек контур из отрезков линий или полиномиальных кривых, а затем на полученных контурах отметить новые точки, соответствующие новой частоте дискретизации.
Способы интерполяции, основанные на свëртке с окном (основным финитным участком импульсной характеристики) какого-нибудь фильтра (гауссова, фильтра Ланцоша, фильтров Слепиана, прямоугольного и т.д.) можно представить себе следующим образом. Допустим, есть в виде кривой некоторый симметричный (относительно вертикальной оси координатной плоскости) колебательный процесс, интенсивность которого быстро убывает по мере удаления от начала координат. Теперь представь точки, расположенные равномерно вдоль горизонтальной, и отстоящие от горизонтальной оси на всякие разные расстояния. Измеряешь эти расстояния, это будут интенсивности отсчëтов исходного сигнала. Дальше масштабируешь упомянутый ранее колебательный процесс в соответствии с интенсивностью каждого отсчëта и перемещаешь увеличенную копию процесса горизонтально из начала координат к координате соответствующего отсчëта. Получилась целая куча накладывающихся друг на друга кривых. Дальше строишь вертикальные прямые, соответствующие новой частоте дискретизации, для каждой из которых находишь точки пересечения с кривыми и алгебраически суммируешь все отклонения точек пересечения от горизонтальной оси (суперпозиция). Вот это суть операции свëртки. Как нетрудно догадаться, окно фильтра можно построить по известным параметрам со сколь угодно высокой частотой дискретизации и сколь угодно большой длины. Вот по этому для такого способа интерполяции соотношения частот дискретизации ограничены только допустимыми искажениями финитности (эффектом Гиббса) и допустимыми искажениями при наложении спектров.
Теперь о том, Что касается фильтра с прямоугольной АЧХ; он же sinc, т.к. обратное преобразование Фурье от прямоугольного спектра - это функция sin(t)/t. Свëртка его импульсной характеристики с исходным дискретным сигналом - это практически лобовое решение восстановительной задачи теоремы Котельникова (т.е. восстановления по дискретным отсчëтам исходного непрерывного сигнала с финитным спектром и ограниченной энергией). Далее в большом алгоритме интерполяции остаëтся только повторно дискретизировать восстановленную модель непрерывного сигнала уже с целевой частотой дискретизации.
Чем отличаются прямоугольный фильтр и фильтр Ланцоша? Окно фильтра Ланцоша состоит из поотсчëтного произвндения двух окон прямоугольных фильтров с разной частотой среза (и, соответственно, разной шириной основного лепестка). Дополнительно отсчëты, близкие к краям окна сделаны нулевыми. Фильтр Ланцоша является улучшением sinc-фильтра, которое при незначительном снижении резкости (за счëт относительного расширенич основного лепестка) значительно снижает переколебания и эффект от наложения смежных окон (за счëт подавления колебательного процесса вблизи краëв окна).
>>2989887
Я что-то сверх меры увлëкся тематикой ЦОС. Попробую ответить на твой вопрос завтра.
Я что-то сверх меры увлëкся тематикой ЦОС. Попробую ответить на твой вопрос завтра.
>>2989949
>>2989957
>>2989958
>>2989967
>>2989980
>>2990032
Охуенная простыня, очень интересно, спасибо что постарался, это действительно важно знать в треде про ffmpeg, программе для кодирования видео и аудио. Все прочитали от начала до конца, математика это же не тупейшая поебень для конченных, и вообще не наука, а хорошее занятие развивающее мозг
>>2989957
>>2989958
>>2989967
>>2989980
>>2990032
Охуенная простыня, очень интересно, спасибо что постарался, это действительно важно знать в треде про ffmpeg, программе для кодирования видео и аудио. Все прочитали от начала до конца, математика это же не тупейшая поебень для конченных, и вообще не наука, а хорошее занятие развивающее мозг
>>2989887
Нет. Я имел в виду, что у mpeg2 не предусмотрено режима кодирования построчного изображения на 30 полных кадров. Только на 60 полей или фильм на 24 кадра с pulldown-флагами.
Итак, чтобы быть точным, я заглянул в стандарт ISO/IEC 13818-2:1995 (E), он же ITU-T Rec. H.262 (1995 E). На 42-ой странице смотрим таблицу 6-4, из которой узнаём, что MPEG-2 поддерживает следующие частоты кадров (кадр определён на 4-ой странице как совокупность всех строк изображения, т. е. совокупность верхнего и нижнего полей — это тоже кадр) и полей:
- 24000/1001 (23.976...) — это тот самый NTSC FILM (т.е. обычный 24-кадровый скан киноплёнки, немного замедленный для совместимости с NTSC-телевидением); поддерживается в вещательной системе ATSC и через программное телекино на DVD/BD и в вещательной системе DVB;
- 24 — это простой FILM; поддерживается в вещательной системе ATSC;
- 25 — это, понятное дело, PAL (построчный и чересстрочный); поддерживается на DVD/BD и в вещательных системах ATSC, DTMB и DVB;
- 30000/1001 (29.97...) — это NTSC; поддерживается на DVD/BD в чересстрочном (и явно не запрещено кодировать материал как построчный) варианте, также поддерживается вещательными системами ATSC, ISDB и DVB;
- 30 — это не предназначено для DVD (для BD нужно уточнить), поддерживается вещательной системой ATSC;
- 50 и 60 — это не предназначено для DVD (редко встречается на UHD BD 60 и 48 кадров/с, но не с MPEG-2), поддерживается вещательными системами ATSC и DVB;
60000/1001 (59.94...) — это не предназначено для DVD/BD, поддерживается вещательными системами ATSC и DVB.
То, что вещательные системы поддерживают, ещё не значит, что реально используется. Подавляющее большинство последовательностей в вещательных системах пытаются сохранять обратную совместимость с частотами кадровой развёртки 25 и 29,97 кадров/с (для PAL и NTSC соответственно).
Никак. Следует различать три формата потока: MPEG-ES (это тот поток, который генерирует кодер, совместимый со стандартом H.262), MPEG-PS (это то, что хранится, например, на DVD в VOB-ах) и MPEG-TS (это то, что предназначено для вещания). MPEG-PS и MPEG-TS — это форматы контейнеров, внутрь которых может с раскладкой и разметкой инкапсулироваться MPEG-ES. Некоторые программы для сборки DVD требуют на свой вход исключительно MPEG-PS, например, dvdauthor. Некоторые программы требуют исключительно MPEG-ES, например, mplex.
Есть нюанс, состоящий в том, что многие пользовательские программы пытаются по расширению файла угадать содержимое. Иногда возникают с этим проблемы.
Для подготовки видео под DVD можно сформулировать основные цепочки:
- (PAL-камера, чересстрочная, 25 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 (если первое должно выводится верхнее полее) или top_field_first=0 (если первым должно выводится нижнее поле) -> поток с чересстрочным PAL-видео;
- (NTSC-камера, чересстрочная, 29,97 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 или top_field_first=0 -> поток с чересстрочным NTSC-видео;
- (PAL-совместимая камера, прогрессивная, 25 или 50 кадров/с) -> монтаж построчного видео с преобразованием частоты кадров из 50 в 25 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным PAL-видео;
- (NTSC-совместимая камера, прогрессивная, 29,97 или 59,94 кадра/с) -> монтаж построчного видео с преобразованием частоты кадров из 59,94 в 29,97 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным NTSC-видео;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 23,976 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным FILM-видео -> расстановка pulldown-флгов, т. е. установка в секции PCE каждого кадра флагов top_field_first и repeat_first_field в зависимости от положения кадра в шаблоне 3:2, такая операция иногда совмещается кодером с кодированием построчного материала;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 25 Гц и увеличением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным PAL-видео;
- (FILM-совместимая камера, прогрессивная, 30 кадров/с) -> монтаж построчного видео с установкой частоты кадров на 29,97 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным NTSC-видео.
Ты используешь какую цепочку преобразований?
> тут нет противоречия?
Нет. Я имел в виду, что у mpeg2 не предусмотрено режима кодирования построчного изображения на 30 полных кадров. Только на 60 полей или фильм на 24 кадра с pulldown-флагами.
Итак, чтобы быть точным, я заглянул в стандарт ISO/IEC 13818-2:1995 (E), он же ITU-T Rec. H.262 (1995 E). На 42-ой странице смотрим таблицу 6-4, из которой узнаём, что MPEG-2 поддерживает следующие частоты кадров (кадр определён на 4-ой странице как совокупность всех строк изображения, т. е. совокупность верхнего и нижнего полей — это тоже кадр) и полей:
- 24000/1001 (23.976...) — это тот самый NTSC FILM (т.е. обычный 24-кадровый скан киноплёнки, немного замедленный для совместимости с NTSC-телевидением); поддерживается в вещательной системе ATSC и через программное телекино на DVD/BD и в вещательной системе DVB;
- 24 — это простой FILM; поддерживается в вещательной системе ATSC;
- 25 — это, понятное дело, PAL (построчный и чересстрочный); поддерживается на DVD/BD и в вещательных системах ATSC, DTMB и DVB;
- 30000/1001 (29.97...) — это NTSC; поддерживается на DVD/BD в чересстрочном (и явно не запрещено кодировать материал как построчный) варианте, также поддерживается вещательными системами ATSC, ISDB и DVB;
- 30 — это не предназначено для DVD (для BD нужно уточнить), поддерживается вещательной системой ATSC;
- 50 и 60 — это не предназначено для DVD (редко встречается на UHD BD 60 и 48 кадров/с, но не с MPEG-2), поддерживается вещательными системами ATSC и DVB;
60000/1001 (59.94...) — это не предназначено для DVD/BD, поддерживается вещательными системами ATSC и DVB.
То, что вещательные системы поддерживают, ещё не значит, что реально используется. Подавляющее большинство последовательностей в вещательных системах пытаются сохранять обратную совместимость с частотами кадровой развёртки 25 и 29,97 кадров/с (для PAL и NTSC соответственно).
> А ну и расширение файла как нибудь влияет на результат? Если ставить m2v, ts? Сейчас ставлю mpg.
Никак. Следует различать три формата потока: MPEG-ES (это тот поток, который генерирует кодер, совместимый со стандартом H.262), MPEG-PS (это то, что хранится, например, на DVD в VOB-ах) и MPEG-TS (это то, что предназначено для вещания). MPEG-PS и MPEG-TS — это форматы контейнеров, внутрь которых может с раскладкой и разметкой инкапсулироваться MPEG-ES. Некоторые программы для сборки DVD требуют на свой вход исключительно MPEG-PS, например, dvdauthor. Некоторые программы требуют исключительно MPEG-ES, например, mplex.
Есть нюанс, состоящий в том, что многие пользовательские программы пытаются по расширению файла угадать содержимое. Иногда возникают с этим проблемы.
> вот например пробовал закодировать ntsc видео для dvd, частоту кадров при кодировании оставил неизменной, потом файл прогнал через dgpulldown.
Для подготовки видео под DVD можно сформулировать основные цепочки:
- (PAL-камера, чересстрочная, 25 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 (если первое должно выводится верхнее полее) или top_field_first=0 (если первым должно выводится нижнее поле) -> поток с чересстрочным PAL-видео;
- (NTSC-камера, чересстрочная, 29,97 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 или top_field_first=0 -> поток с чересстрочным NTSC-видео;
- (PAL-совместимая камера, прогрессивная, 25 или 50 кадров/с) -> монтаж построчного видео с преобразованием частоты кадров из 50 в 25 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным PAL-видео;
- (NTSC-совместимая камера, прогрессивная, 29,97 или 59,94 кадра/с) -> монтаж построчного видео с преобразованием частоты кадров из 59,94 в 29,97 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным NTSC-видео;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 23,976 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным FILM-видео -> расстановка pulldown-флгов, т. е. установка в секции PCE каждого кадра флагов top_field_first и repeat_first_field в зависимости от положения кадра в шаблоне 3:2, такая операция иногда совмещается кодером с кодированием построчного материала;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 25 Гц и увеличением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным PAL-видео;
- (FILM-совместимая камера, прогрессивная, 30 кадров/с) -> монтаж построчного видео с установкой частоты кадров на 29,97 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным NTSC-видео.
Ты используешь какую цепочку преобразований?
>>2989887
Нет. Я имел в виду, что у mpeg2 не предусмотрено режима кодирования построчного изображения на 30 полных кадров. Только на 60 полей или фильм на 24 кадра с pulldown-флагами.
Итак, чтобы быть точным, я заглянул в стандарт ISO/IEC 13818-2:1995 (E), он же ITU-T Rec. H.262 (1995 E). На 42-ой странице смотрим таблицу 6-4, из которой узнаём, что MPEG-2 поддерживает следующие частоты кадров (кадр определён на 4-ой странице как совокупность всех строк изображения, т. е. совокупность верхнего и нижнего полей — это тоже кадр) и полей:
- 24000/1001 (23.976...) — это тот самый NTSC FILM (т.е. обычный 24-кадровый скан киноплёнки, немного замедленный для совместимости с NTSC-телевидением); поддерживается в вещательной системе ATSC и через программное телекино на DVD/BD и в вещательной системе DVB;
- 24 — это простой FILM; поддерживается в вещательной системе ATSC;
- 25 — это, понятное дело, PAL (построчный и чересстрочный); поддерживается на DVD/BD и в вещательных системах ATSC, DTMB и DVB;
- 30000/1001 (29.97...) — это NTSC; поддерживается на DVD/BD в чересстрочном (и явно не запрещено кодировать материал как построчный) варианте, также поддерживается вещательными системами ATSC, ISDB и DVB;
- 30 — это не предназначено для DVD (для BD нужно уточнить), поддерживается вещательной системой ATSC;
- 50 и 60 — это не предназначено для DVD (редко встречается на UHD BD 60 и 48 кадров/с, но не с MPEG-2), поддерживается вещательными системами ATSC и DVB;
60000/1001 (59.94...) — это не предназначено для DVD/BD, поддерживается вещательными системами ATSC и DVB.
То, что вещательные системы поддерживают, ещё не значит, что реально используется. Подавляющее большинство последовательностей в вещательных системах пытаются сохранять обратную совместимость с частотами кадровой развёртки 25 и 29,97 кадров/с (для PAL и NTSC соответственно).
Никак. Следует различать три формата потока: MPEG-ES (это тот поток, который генерирует кодер, совместимый со стандартом H.262), MPEG-PS (это то, что хранится, например, на DVD в VOB-ах) и MPEG-TS (это то, что предназначено для вещания). MPEG-PS и MPEG-TS — это форматы контейнеров, внутрь которых может с раскладкой и разметкой инкапсулироваться MPEG-ES. Некоторые программы для сборки DVD требуют на свой вход исключительно MPEG-PS, например, dvdauthor. Некоторые программы требуют исключительно MPEG-ES, например, mplex.
Есть нюанс, состоящий в том, что многие пользовательские программы пытаются по расширению файла угадать содержимое. Иногда возникают с этим проблемы.
Для подготовки видео под DVD можно сформулировать основные цепочки:
- (PAL-камера, чересстрочная, 25 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 (если первое должно выводится верхнее полее) или top_field_first=0 (если первым должно выводится нижнее поле) -> поток с чересстрочным PAL-видео;
- (NTSC-камера, чересстрочная, 29,97 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 или top_field_first=0 -> поток с чересстрочным NTSC-видео;
- (PAL-совместимая камера, прогрессивная, 25 или 50 кадров/с) -> монтаж построчного видео с преобразованием частоты кадров из 50 в 25 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным PAL-видео;
- (NTSC-совместимая камера, прогрессивная, 29,97 или 59,94 кадра/с) -> монтаж построчного видео с преобразованием частоты кадров из 59,94 в 29,97 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным NTSC-видео;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 23,976 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным FILM-видео -> расстановка pulldown-флгов, т. е. установка в секции PCE каждого кадра флагов top_field_first и repeat_first_field в зависимости от положения кадра в шаблоне 3:2, такая операция иногда совмещается кодером с кодированием построчного материала;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 25 Гц и увеличением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным PAL-видео;
- (FILM-совместимая камера, прогрессивная, 30 кадров/с) -> монтаж построчного видео с установкой частоты кадров на 29,97 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным NTSC-видео.
Ты используешь какую цепочку преобразований?
> тут нет противоречия?
Нет. Я имел в виду, что у mpeg2 не предусмотрено режима кодирования построчного изображения на 30 полных кадров. Только на 60 полей или фильм на 24 кадра с pulldown-флагами.
Итак, чтобы быть точным, я заглянул в стандарт ISO/IEC 13818-2:1995 (E), он же ITU-T Rec. H.262 (1995 E). На 42-ой странице смотрим таблицу 6-4, из которой узнаём, что MPEG-2 поддерживает следующие частоты кадров (кадр определён на 4-ой странице как совокупность всех строк изображения, т. е. совокупность верхнего и нижнего полей — это тоже кадр) и полей:
- 24000/1001 (23.976...) — это тот самый NTSC FILM (т.е. обычный 24-кадровый скан киноплёнки, немного замедленный для совместимости с NTSC-телевидением); поддерживается в вещательной системе ATSC и через программное телекино на DVD/BD и в вещательной системе DVB;
- 24 — это простой FILM; поддерживается в вещательной системе ATSC;
- 25 — это, понятное дело, PAL (построчный и чересстрочный); поддерживается на DVD/BD и в вещательных системах ATSC, DTMB и DVB;
- 30000/1001 (29.97...) — это NTSC; поддерживается на DVD/BD в чересстрочном (и явно не запрещено кодировать материал как построчный) варианте, также поддерживается вещательными системами ATSC, ISDB и DVB;
- 30 — это не предназначено для DVD (для BD нужно уточнить), поддерживается вещательной системой ATSC;
- 50 и 60 — это не предназначено для DVD (редко встречается на UHD BD 60 и 48 кадров/с, но не с MPEG-2), поддерживается вещательными системами ATSC и DVB;
60000/1001 (59.94...) — это не предназначено для DVD/BD, поддерживается вещательными системами ATSC и DVB.
То, что вещательные системы поддерживают, ещё не значит, что реально используется. Подавляющее большинство последовательностей в вещательных системах пытаются сохранять обратную совместимость с частотами кадровой развёртки 25 и 29,97 кадров/с (для PAL и NTSC соответственно).
> А ну и расширение файла как нибудь влияет на результат? Если ставить m2v, ts? Сейчас ставлю mpg.
Никак. Следует различать три формата потока: MPEG-ES (это тот поток, который генерирует кодер, совместимый со стандартом H.262), MPEG-PS (это то, что хранится, например, на DVD в VOB-ах) и MPEG-TS (это то, что предназначено для вещания). MPEG-PS и MPEG-TS — это форматы контейнеров, внутрь которых может с раскладкой и разметкой инкапсулироваться MPEG-ES. Некоторые программы для сборки DVD требуют на свой вход исключительно MPEG-PS, например, dvdauthor. Некоторые программы требуют исключительно MPEG-ES, например, mplex.
Есть нюанс, состоящий в том, что многие пользовательские программы пытаются по расширению файла угадать содержимое. Иногда возникают с этим проблемы.
> вот например пробовал закодировать ntsc видео для dvd, частоту кадров при кодировании оставил неизменной, потом файл прогнал через dgpulldown.
Для подготовки видео под DVD можно сформулировать основные цепочки:
- (PAL-камера, чересстрочная, 25 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 (если первое должно выводится верхнее полее) или top_field_first=0 (если первым должно выводится нижнее поле) -> поток с чересстрочным PAL-видео;
- (NTSC-камера, чересстрочная, 29,97 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 или top_field_first=0 -> поток с чересстрочным NTSC-видео;
- (PAL-совместимая камера, прогрессивная, 25 или 50 кадров/с) -> монтаж построчного видео с преобразованием частоты кадров из 50 в 25 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным PAL-видео;
- (NTSC-совместимая камера, прогрессивная, 29,97 или 59,94 кадра/с) -> монтаж построчного видео с преобразованием частоты кадров из 59,94 в 29,97 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным NTSC-видео;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 23,976 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным FILM-видео -> расстановка pulldown-флгов, т. е. установка в секции PCE каждого кадра флагов top_field_first и repeat_first_field в зависимости от положения кадра в шаблоне 3:2, такая операция иногда совмещается кодером с кодированием построчного материала;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 25 Гц и увеличением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным PAL-видео;
- (FILM-совместимая камера, прогрессивная, 30 кадров/с) -> монтаж построчного видео с установкой частоты кадров на 29,97 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным NTSC-видео.
Ты используешь какую цепочку преобразований?
1 Мб, webm,650x520, 0:12
>>2989949
> Между ФНЧ при передискретизации есть следующая разница.
> Наименьшие искажения даёт гауссовский фильтр из-за того, что гауссовская функция является собственной функцией преобразования Фурье; наименьшие искажения достигаются при большом размере окна, т.к. гауссовская функция не финитная, на практике из соображения производительности выбирают окно из 32...64 отсчётов, что даёт СКО за счёт эффекта Гиббса в районе -40 дБ; плюс при малой ширине лепестка (для более чёткой картинки) на изображении вблизи границы между статичной текстурой и резким краем другого объекта будут заметны изкажения, воспринимаемые как шум; требуется внимательный подбор пареметра ширины лепестка и, если предоставляется, ширины окна. Фильтр почти не обогощает спектр и не даёт переколебаний вблизи резких колебаний яркости.
141 Кб, 1420x1068>>2989887
В свойствах видеопоследовательности, если у тебя комбайн. В настройках кодера, если у тебя отдельный кодер.
Приведу пример с hcenc на картинке.
В ffmpeg кодер mpeg2video из состава libavcodec по умолчанию кодирует построчный материал. Чтобы кодировать чересстрочный материал нужно явно сообщить ffmpeg опции «-ilme», «-ildct» и «-ildctcmp». Последняя опция должна быть с параметром. Кроме того, в зависимости от входного материала, может потребоваться указать явно порядок полей «-field_order» (тоже с параметром).
Для построчного видео последний раз использовал такие строчки для двух проходов:
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 1 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -b_strategy 2 -brd_scale 0 -b_sensitivity 40 \
-qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
/dev/null -y && \
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 2 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
ed-film.vob -y
>>Если материал построчеый, то не забывай об этом программе кодирования сообщить.
>Как?
В свойствах видеопоследовательности, если у тебя комбайн. В настройках кодера, если у тебя отдельный кодер.
Приведу пример с hcenc на картинке.
В ffmpeg кодер mpeg2video из состава libavcodec по умолчанию кодирует построчный материал. Чтобы кодировать чересстрочный материал нужно явно сообщить ffmpeg опции «-ilme», «-ildct» и «-ildctcmp». Последняя опция должна быть с параметром. Кроме того, в зависимости от входного материала, может потребоваться указать явно порядок полей «-field_order» (тоже с параметром).
Для построчного видео последний раз использовал такие строчки для двух проходов:
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 1 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -b_strategy 2 -brd_scale 0 -b_sensitivity 40 \
-qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
/dev/null -y && \
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 2 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
ed-film.vob -y
141 Кб, 1420x1068>>2989887
В свойствах видеопоследовательности, если у тебя комбайн. В настройках кодера, если у тебя отдельный кодер.
Приведу пример с hcenc на картинке.
В ffmpeg кодер mpeg2video из состава libavcodec по умолчанию кодирует построчный материал. Чтобы кодировать чересстрочный материал нужно явно сообщить ffmpeg опции «-ilme», «-ildct» и «-ildctcmp». Последняя опция должна быть с параметром. Кроме того, в зависимости от входного материала, может потребоваться указать явно порядок полей «-field_order» (тоже с параметром).
Для построчного видео последний раз использовал такие строчки для двух проходов:
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 1 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -b_strategy 2 -brd_scale 0 -b_sensitivity 40 \
-qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
/dev/null -y && \
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 2 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
ed-film.vob -y
>>Если материал построчеый, то не забывай об этом программе кодирования сообщить.
>Как?
В свойствах видеопоследовательности, если у тебя комбайн. В настройках кодера, если у тебя отдельный кодер.
Приведу пример с hcenc на картинке.
В ffmpeg кодер mpeg2video из состава libavcodec по умолчанию кодирует построчный материал. Чтобы кодировать чересстрочный материал нужно явно сообщить ffmpeg опции «-ilme», «-ildct» и «-ildctcmp». Последняя опция должна быть с параметром. Кроме того, в зависимости от входного материала, может потребоваться указать явно порядок полей «-field_order» (тоже с параметром).
Для построчного видео последний раз использовал такие строчки для двух проходов:
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 1 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -b_strategy 2 -brd_scale 0 -b_sensitivity 40 \
-qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
/dev/null -y && \
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 2 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
ed-film.vob -y
412 Кб, 800x1097>>2990480
Как ты лихо всех, кого ты не понимаешь, относишь к категории «ебанутые»?
Чтобы понимать то, о чём я говорю, можно, например почитать вот эти две книжки:
- Чобану М. К. Многомерные многоскоростные системы обработки сигналов. М.: Техносфера, 2009;
- Дворкович В.П., Дворкович А.В. Оконные функции для гармонического анализа сигналов /Издание второе, переработанное и дополненное/ М.: Техносфера, 2016.
>>2990111
Здесь, скорее, случай на картинке.
Как ты лихо всех, кого ты не понимаешь, относишь к категории «ебанутые»?
Чтобы понимать то, о чём я говорю, можно, например почитать вот эти две книжки:
- Чобану М. К. Многомерные многоскоростные системы обработки сигналов. М.: Техносфера, 2009;
- Дворкович В.П., Дворкович А.В. Оконные функции для гармонического анализа сигналов /Издание второе, переработанное и дополненное/ М.: Техносфера, 2016.
>>2990111
Здесь, скорее, случай на картинке.
>>2990551
Дегенерат, спок.
Дегенерат, спок.
>>2990551
Дополнительно сообщу, что есть отличный обзор в документации к ImageMagick:
https://legacy.imagemagick.org/Usage/filter/
Дополнительно сообщу, что есть отличный обзор в документации к ImageMagick:
https://legacy.imagemagick.org/Usage/filter/
>>2990706
Если ты про
То имею сказать следующее
Читаем функцию select_input_picture(MpegEncContext s) и убеждаемся, что b_frame_strategy и b_sensitivity используются одновременно, а brd_scale используется в вызываемой там же функции estimate_best_b_count(MpegEncContext s).
Но только при b_frame_strategy==1 используется b_sensitivity. Следовательно, можно опцию смело исключить и написать правильно сразу:
-b_strategy 2 -brd_scale 0
И это опция только для первого прохода.
Плюс в 2016 году опции b_strategy и brd_scale перевели в устаревшие (в смысле, что из общей структуры AVCodecContext её нужно перенести в структуру MpegEncContext)
https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2016-January/097741.html
Т. е. как правильно использовать, нужно узнавать такой командой:
ffmpeg -h encoder=mpeg2video
Я использую правильно, за исключением избыточного указания опции b_sensitivity.
Такие дела.
> параметры немного отличаются это норм?
Если ты про
> -b_strategy 2 -brd_scale 0 -b_sensitivity 40
То имею сказать следующее
> -b_strategy 2
> mpegvideo_enc.c, 723
> b_frame_strategy only affects the first pass
> -b_sensitivity 40
> mpegvideo_enc.c, 1561
Читаем функцию select_input_picture(MpegEncContext s) и убеждаемся, что b_frame_strategy и b_sensitivity используются одновременно, а brd_scale используется в вызываемой там же функции estimate_best_b_count(MpegEncContext s).
Но только при b_frame_strategy==1 используется b_sensitivity. Следовательно, можно опцию смело исключить и написать правильно сразу:
-b_strategy 2 -brd_scale 0
И это опция только для первого прохода.
Плюс в 2016 году опции b_strategy и brd_scale перевели в устаревшие (в смысле, что из общей структуры AVCodecContext её нужно перенести в структуру MpegEncContext)
https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2016-January/097741.html
Т. е. как правильно использовать, нужно узнавать такой командой:
ffmpeg -h encoder=mpeg2video
Я использую правильно, за исключением избыточного указания опции b_sensitivity.
Такие дела.
>>2990706
Тогда идём по схеме
с той разницей, что звук у нас уже нужной длины, и правильная частота кадров выставлена. Т. е. просто кодируем построчное видео. Т.к. ты собираешься расставлять pulldown-флаги при помощи dgpulldown, то тебе понадобиться на выходе кодера иметь чистый MPEG-ES (или MPEG-2 Video Stream). Если заставлять ffmpeg такой поток записывать, то указать ей нужно опцию
-f mpeg2video
Но можно и из любого другого контейнера raw MPEG-2 Video достать. Например, той же dgindex или mpegdemux или ffmpeg.
Как-то так.
>Пытаюсь сконвертировать скачанный bdrip у которого кадры прогрессивные и fps 23.976
Тогда идём по схеме
> (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 23,976 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным FILM-видео -> расстановка pulldown-флгов, т. е. установка в секции PCE каждого кадра флагов top_field_first и repeat_first_field в зависимости от положения кадра в шаблоне 3:2, такая операция иногда совмещается кодером с кодированием построчного материала
с той разницей, что звук у нас уже нужной длины, и правильная частота кадров выставлена. Т. е. просто кодируем построчное видео. Т.к. ты собираешься расставлять pulldown-флаги при помощи dgpulldown, то тебе понадобиться на выходе кодера иметь чистый MPEG-ES (или MPEG-2 Video Stream). Если заставлять ffmpeg такой поток записывать, то указать ей нужно опцию
-f mpeg2video
Но можно и из любого другого контейнера raw MPEG-2 Video достать. Например, той же dgindex или mpegdemux или ffmpeg.
Как-то так.
>>2990706
«Сверху и сниху телеэкрана невыносимо темнеют полоски».
У меня в тестовом видео кадр 720×480 с отношением сторон 16:9, без полосок. Такой исходник.
В скрипте avisynth. Я считаю, что объявить фильтры и монтажные процедуры в avisynth проще, чем в параметрах ffmpeg. Подумываю перейти на vapoursynth.
>леттербокс
«Сверху и сниху телеэкрана невыносимо темнеют полоски».
У меня в тестовом видео кадр 720×480 с отношением сторон 16:9, без полосок. Такой исходник.
> где у тебя происходит изменение размера изображения
В скрипте avisynth. Я считаю, что объявить фильтры и монтажные процедуры в avisynth проще, чем в параметрах ffmpeg. Подумываю перейти на vapoursynth.
>>2987746
После того, как я освежил в памяти текст стандарта, расскажу, что для твоего случая (23,976 построчных кадра в секунду) в заголовке потока будет стоять флаг progressive_sequence==1, а в структуре «Picture coding extension» в заголовке каждого кадра будет установлен флаг progressive_frame==1 и определена пара флагов top_field_first и repeat_first_field, которые будут определять способ сборки дополнительных пар полей из чётных и нечётных строк построчного кадра.
Вот цитата из обзорной части стандарта:
>А на ntsc dvd как хранится видео?
> а откуда тогда будут браться чересстрочные поля?
После того, как я освежил в памяти текст стандарта, расскажу, что для твоего случая (23,976 построчных кадра в секунду) в заголовке потока будет стоять флаг progressive_sequence==1, а в структуре «Picture coding extension» в заголовке каждого кадра будет установлен флаг progressive_frame==1 и определена пара флагов top_field_first и repeat_first_field, которые будут определять способ сборки дополнительных пар полей из чётных и нечётных строк построчного кадра.
Вот цитата из обзорной части стандарта:
> A decoder can implement 3:2 pull down when a sequence of progressive pictures is encoded. Each encoded movie picture can independently specify whether it is displayed for two or three video field periods, so “irregular” 3:2 pull down source material can be transmitted as progressive video. Two flags, top_field_first and repeat_first_field, are transmitted with the Picture Coding Extensions and adequately describe the necessary display timing.
я нагуглил миллион ссылок как сделать с помощью ffmpeg гифку, но не нашёл ничего про то как сделать из гифки видео. ffmpeg так не умеет что ли? гуй в виде FFmpeg_Batch_2.4.0 есть гифки отказался.
>>2990814
ffmpeg -i gif.gif out.mp4
ffmpeg -i gif.gif out.mp4
>>2990775
спасибо за развернутые ответы. а для преобразования 23.976 в 25 fps (для pal dvd) pulldown будет работать?
спасибо за развернутые ответы. а для преобразования 23.976 в 25 fps (для pal dvd) pulldown будет работать?
>>2991204
Пожалуйста. Рад помочь.
Для начала нужно будет картинку 720x576 подготовить. Способ повторить строки по шаблону 23,976->25 есть, и о нëм знает dgpulldown. Просто результат такого преобразоаания на телевизоре будет выглядеть не очень. Рваное движение заметно и на 23,976->29,97, а на 23,976->25 будет явно бросаться в глаза. При подготовке изданий в PAL, как правило, ускоряют звук и видео до 25 кадров. Сильно раньше было ещë заметно по музыке ускорение, а сегодня есть преобразователи с сохранением тона. Опять же, ты делаешь не официальное издание, бытовую копию - наверняка для тебя небольшое смещение тонов вверх в звуковой дорожке будет терпимо.
> спасибо за развернутые ответы.
Пожалуйста. Рад помочь.
> а для преобразования 23.976 в 25 fps (для pal dvd) pulldown будет работать?
Для начала нужно будет картинку 720x576 подготовить. Способ повторить строки по шаблону 23,976->25 есть, и о нëм знает dgpulldown. Просто результат такого преобразоаания на телевизоре будет выглядеть не очень. Рваное движение заметно и на 23,976->29,97, а на 23,976->25 будет явно бросаться в глаза. При подготовке изданий в PAL, как правило, ускоряют звук и видео до 25 кадров. Сильно раньше было ещë заметно по музыке ускорение, а сегодня есть преобразователи с сохранением тона. Опять же, ты делаешь не официальное издание, бытовую копию - наверняка для тебя небольшое смещение тонов вверх в звуковой дорожке будет терпимо.
>>2990532
по ффмпеговской справке у этого параметра значение по умолчанию 256, есть какой то особый смысл в том чтобы задавать его явно(также как у еще у нескольких)?
>mv0_threshold 256
по ффмпеговской справке у этого параметра значение по умолчанию 256, есть какой то особый смысл в том чтобы задавать его явно(также как у еще у нескольких)?
>>2991497
Нет. Никакого нет смысла. Эту строчку я взял из своего исследования кодера libavcoec::mpeg2video там я пытался решить оптимизационную задачу с критерием SSIM относительно параметров. Поскольку в скрипте они все указаны явно (т. к. я веду поиск по множеству допустимых для них значений), то и в строчку попали в том же виде. Два года или три даже прошло — я уже плохо помню, какие значения по умолчанию там. Но да, те, которые совпадают с умолчаниями, можно опустить.
> есть какой то особый смысл в том чтобы задавать его явно
Нет. Никакого нет смысла. Эту строчку я взял из своего исследования кодера libavcoec::mpeg2video там я пытался решить оптимизационную задачу с критерием SSIM относительно параметров. Поскольку в скрипте они все указаны явно (т. к. я веду поиск по множеству допустимых для них значений), то и в строчку попали в том же виде. Два года или три даже прошло — я уже плохо помню, какие значения по умолчанию там. Но да, те, которые совпадают с умолчаниями, можно опустить.
У меня есть много видео с высоким разрешением и битрейтом, которые плохо проигрываются на моём некрокомпе. Как можно если это возможно через .bat файл, массово понизить разрешение и битрейт и можно как нибудь, кроме метода тыка узнать комфортный для твоей машины битрейт?
>>2993207
Для этого нужна модель видеокарты и процессора. И информация о лагающих видео. Скачай DXVA Checker и скинь сюда скрин
Для этого нужна модель видеокарты и процессора. И информация о лагающих видео. Скачай DXVA Checker и скинь сюда скрин
>>2993276
Для чего нужна? Скажи, что ты собирался смотреть, я сам посмотрю. Мне главное понять, как пачку видео под нужные параметры кодировать. Лагают видео от 1980 до 4K. Битрейт по моему предыдущему опыту где то от 1000 лучше ставить.
Для чего нужна? Скажи, что ты собирался смотреть, я сам посмотрю. Мне главное понять, как пачку видео под нужные параметры кодировать. Лагают видео от 1980 до 4K. Битрейт по моему предыдущему опыту где то от 1000 лучше ставить.
>>2993329
DXVA Checker показывает поддерживаемые кодеки и максимальное разрешение. Вот выбираешь какой-нибудь из них и кодируешь в него, будет воспроизводиться без лагов
Лагает в зависимости от битрейта только если видеокарта не поддерживает кодек, и его обрабатывает процессор
DXVA Checker показывает поддерживаемые кодеки и максимальное разрешение. Вот выбираешь какой-нибудь из них и кодируешь в него, будет воспроизводиться без лагов
Лагает в зависимости от битрейта только если видеокарта не поддерживает кодек, и его обрабатывает процессор
>>2993207
Ну, есть на твой вопрос три варианта ответа:
- научный,
- научно-популярный и
- бытовой.
Тебя, как я понимаю, интересует бытовой.
Чтобы бытовой (и при этом не тривиальный вроде, «купи уже мощный комплюктер в спальню») ответ сформулировать, нужно уточнить кое-какие множества из твоей задачи:
- модель центрального процессора,
-модель видеоадаптера графического ускорителя;
- характеристики файлов (по mediainfo, в текстовом виде) — нужно как минимум два файла: тот, который играется невыносимо медленно, и тот, который играется ещё сносно, но уже начинает притормаживать.
> высоким разрешением и битрейтом, которые плохо проигрываются на моём некрокомпе
> комфортный для твоей машины битрейт
Ну, есть на твой вопрос три варианта ответа:
- научный,
- научно-популярный и
- бытовой.
Тебя, как я понимаю, интересует бытовой.
Чтобы бытовой (и при этом не тривиальный вроде, «купи уже мощный комплюктер в спальню») ответ сформулировать, нужно уточнить кое-какие множества из твоей задачи:
- модель центрального процессора,
-модель видеоадаптера графического ускорителя;
- характеристики файлов (по mediainfo, в текстовом виде) — нужно как минимум два файла: тот, который играется невыносимо медленно, и тот, который играется ещё сносно, но уже начинает притормаживать.
>>2993207
Да, можно. Но если в файлах зоопарк, то скрипт не обещает быть простым.
> Как можно если это возможно через .bat файл, массово понизить разрешение и битрейт
Да, можно. Но если в файлах зоопарк, то скрипт не обещает быть простым.
>>2993207
а зачем тебе восьмёрка на некрокомпе?
а зачем тебе восьмёрка на некрокомпе?
Может кто знает есть ли кастомные фильтры, типа beautify, bloom, сепия и т.д.? Может хотя бы графы готовые есть? Я знаю блум, например, точно можно собрать из имеющихся, но в лом ебаться - ффмпег же нихуя не интерактивный.
>>2979843 (OP)
Существует ли аналог ffmpeg для изображений?
Существует ли аналог ffmpeg для изображений?
>>2997306
ffmpeg и так умеет работать с изображениями.
ffmpeg и так умеет работать с изображениями.
>>2997306
imagemagick
imagemagick
Нормальный какой фронтенд есть чтобы отображал видеодорожки? Их вроде бы много, но как правило рыгают терабайтными файлами, ставят ватермарки, ещё бывает браузер (либо макаба ломает) не понимает mp4 результат и воспроизводит только звук
>>2979843 (OP)
Существуют ли хоть сколько-нибудь годные GUI для сабжа под винду, раскрывающие как можно больше его потанцевала?
Натыкался пару раз на MeGUI и HandBrake, но это как я понимаю, немного из другой темы, ведь они только де/кодируют видео?
Существуют ли хоть сколько-нибудь годные GUI для сабжа под винду, раскрывающие как можно больше его потанцевала?
Натыкался пару раз на MeGUI и HandBrake, но это как я понимаю, немного из другой темы, ведь они только де/кодируют видео?
>>2997779
Это-то понятно, MeGUI вроде тоже так умеет (но для этого проще взять AviDemux). Но меня интересуют также другие свистоперделки, например создание и редактирование видео (эффекты там всякие, или что сабж умеет), захват экрана.
Это-то понятно, MeGUI вроде тоже так умеет (но для этого проще взять AviDemux). Но меня интересуют также другие свистоперделки, например создание и редактирование видео (эффекты там всякие, или что сабж умеет), захват экрана.
>>2997782
То, что ты описал, уже выходит за рамки простого гуя под винду.
Kdenlive, shotcut (насколько помню, у него как раз ffmpeg под капотом), вот это вот всё.
То, что ты описал, уже выходит за рамки простого гуя под винду.
Kdenlive, shotcut (насколько помню, у него как раз ffmpeg под капотом), вот это вот всё.
>>2997778
Из того что успел сам попробовать и остановился на них:
https://www.shutterencoder.com/en/
https://www.xmedia-recode.de/en/download.php
Из того что успел сам попробовать и остановился на них:
https://www.shutterencoder.com/en/
https://www.xmedia-recode.de/en/download.php
Нужно объединить звук из нескольких flac-файлов с именами "001.flac, 002.flac, 003.flac, ..." в один flac-файл, чтобы между звуком разных файлов не было пауз, щелчков и прочего. Как это сделать? Несколько "-i" не сработало.
>>2998171
Что именно не сработало? Между файлами задержки и т.д.? Этих задержек случайно нет в самих файлах? Или выдаёт ошибку? Тогда какую? В общем, подробностей бы.
В документации https://trac.ffmpeg.org/wiki/Concatenate советуют этот метод:
file 'c:\documents\001.flac'
file 'c:\documents\002.flac'
file 'c:\documents\003.flac'
Если не проходит, попробуй указать относительные пути либо сменить "\" на "/"
Не забываем запускать команду из папки с лежащим текстовиком либо указываем к нему путь
Что именно не сработало? Между файлами задержки и т.д.? Этих задержек случайно нет в самих файлах? Или выдаёт ошибку? Тогда какую? В общем, подробностей бы.
В документации https://trac.ffmpeg.org/wiki/Concatenate советуют этот метод:
> создаёшь текстовый файл mylist.txt
file 'c:\documents\001.flac'
file 'c:\documents\002.flac'
file 'c:\documents\003.flac'
Если не проходит, попробуй указать относительные пути либо сменить "\" на "/"
> ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.flac
Не забываем запускать команду из папки с лежащим текстовиком либо указываем к нему путь
>>2998201
у меня похожая задача.
но есть проблема.
есть много видеофайлов, но у них отличаются частота кадров и разрешение. кодек один.
при попытке конкатнуть с изменением разрешения и частоты кадров, появляются ошибки.
как соединить эти видюхи?
у меня похожая задача.
но есть проблема.
есть много видеофайлов, но у них отличаются частота кадров и разрешение. кодек один.
при попытке конкатнуть с изменением разрешения и частоты кадров, появляются ошибки.
как соединить эти видюхи?
>>2998621
Ну дак, определяем параметры исходного видео - каким будет размер/фреймрейт - максимальные/минимальные из всех видео, ну либо свои параметры. И перегоняем каждое видео к нужному размеру/фреймрейту. Потом склеиваем. Надеюсь не нужно пояснять, как менять размер и частоту кадров у одного видео? Да и простого ответа тут нет, зависит от задачи
Ещё раз, сначала нужно привести все видео к одинаковым параметрам, и только потом склеить, базовое правило видеомонтажа. Естественно не обойдётся без перекодирования.
Вот тут рассказывают, как ресайзнуть (фиксированно, либо с соотношением сторон, думаю тебе подойдёт именно фиксированный ресайз + обрезка кадра при несовпадении пропорций если не нужна деформация {я на самом деле хз, фиксированный ресайз обрезает или искажает, лучше перепроверить}): https://poweruser.guru/q/624563/#624564 , с изменением фреймрейта всё сложнее, тут лучше самому погуглить.
Одной командой сделать это наверняка нельзя, но точно я не знаю дилетант ещё тот, поэтому утверждать не буду.
Ну дак, определяем параметры исходного видео - каким будет размер/фреймрейт - максимальные/минимальные из всех видео, ну либо свои параметры. И перегоняем каждое видео к нужному размеру/фреймрейту. Потом склеиваем. Надеюсь не нужно пояснять, как менять размер и частоту кадров у одного видео? Да и простого ответа тут нет, зависит от задачи
Ещё раз, сначала нужно привести все видео к одинаковым параметрам, и только потом склеить, базовое правило видеомонтажа. Естественно не обойдётся без перекодирования.
Вот тут рассказывают, как ресайзнуть (фиксированно, либо с соотношением сторон, думаю тебе подойдёт именно фиксированный ресайз + обрезка кадра при несовпадении пропорций если не нужна деформация {я на самом деле хз, фиксированный ресайз обрезает или искажает, лучше перепроверить}): https://poweruser.guru/q/624563/#624564 , с изменением фреймрейта всё сложнее, тут лучше самому погуглить.
Одной командой сделать это наверняка нельзя, но точно я не знаю дилетант ещё тот, поэтому утверждать не буду.
Я правильно понял, что 2pass даёт больше битрейта динамичным сценам, а crf – наоборот?
>>2998693
получается, итоговое видео будет иметь наименьшую частоту кадров, представленных в видюхах?
получается, итоговое видео будет иметь наименьшую частоту кадров, представленных в видюхах?
>>2996746
Вот есть объяснения на английском для прилежного выпускника средней школы >>2990625.
>>2996778
Нет, окошко Ланцоша не является «лучшим».
Оно среди родственников является твëрдым середнячком.
>>2997513
Чем тебе mediainfo не нравится?
>>2997778
Я с годами понял, что GUI для ffmpeg - это что-то противоестественное. Тем более, НЯП, cmd.exe наконец-то научилась в drag-n-drop (вставлять в строчку имя файла при перетаскивании значка в окошко).
>>2998621
Разрешение придëтся приводить к одному. Воспроизводящие устройства к такому, как правило, не готовы, программы то же. С частотой кадров всë ещë хуже. Нет годного способа еë преобразования - все чем-нибудь плохи. Пока сама задача слишком плоха, чтобы было хорошее решение.
>>2998728
Нет. Двухпроходная стратегия контроллера ширины потока ставит задачу получить среднюю ширину потока при малой дисперсии квантователя. CRF-стратегия удерживает малые отклонения квантователя (по Чебышëву), увеличивая его только при предельных характеристиках потока, определëнных для профиля и уровня.
Вот есть объяснения на английском для прилежного выпускника средней школы >>2990625.
>>2996778
Нет, окошко Ланцоша не является «лучшим».
Оно среди родственников является твëрдым середнячком.
>>2997513
Чем тебе mediainfo не нравится?
>>2997778
Я с годами понял, что GUI для ffmpeg - это что-то противоестественное. Тем более, НЯП, cmd.exe наконец-то научилась в drag-n-drop (вставлять в строчку имя файла при перетаскивании значка в окошко).
>>2998621
> отличаются частота кадров и разрешение
Разрешение придëтся приводить к одному. Воспроизводящие устройства к такому, как правило, не готовы, программы то же. С частотой кадров всë ещë хуже. Нет годного способа еë преобразования - все чем-нибудь плохи. Пока сама задача слишком плоха, чтобы было хорошее решение.
>>2998728
Нет. Двухпроходная стратегия контроллера ширины потока ставит задачу получить среднюю ширину потока при малой дисперсии квантователя. CRF-стратегия удерживает малые отклонения квантователя (по Чебышëву), увеличивая его только при предельных характеристиках потока, определëнных для профиля и уровня.
>>2998729
Почему не нужен?
>>2998732
Что это значит?
Почему не нужен?
>>2998732
>Нет. Двухпроходная стратегия контроллера ширины потока ставит задачу получить среднюю ширину потока при малой дисперсии квантователя. CRF-стратегия удерживает малые отклонения квантователя (по Чебышëву), увеличивая его только при предельных характеристиках потока, определëнных для профиля и уровня.
Что это значит?
>>2998732
В ffmpeg другого нет. И какие ещё родственники?
>>2998740
От него лучше качество не становится. Это требуется только когда у тебя ограничение по размеру файла. Но 264 и 265 умеют нормально его соблюдать с первого раза.
> Нет, окошко Ланцоша не является «лучшим».
> Оно среди родственников является твëрдым середнячком.
В ffmpeg другого нет. И какие ещё родственники?
>>2998740
> Почему не нужен?
От него лучше качество не становится. Это требуется только когда у тебя ограничение по размеру файла. Но 264 и 265 умеют нормально его соблюдать с первого раза.
>>2998889
Хуесос, спок.
Хуесос, спок.
>>2998743
https://pastebin.com/iVjMRr7s
Это выхлоп ffmpeg 2.8. В нём указаны следующие фильтры: fast_bilinear, bilinear, bicubic, experimental, neighbor, area, gauss, sinc, lanczos, spline.
Для современного ffmpeg можно посмотреть хотябы исходный код:
https://ffmpeg.org/doxygen/trunk/swscale_8h_source.html#l00057
В нём указаны уже следующие фильтры: fast_bilinear, bilinear, bicubic, experimental, point (он же neighbor), area, gauss, sinc, lanczos, spline. То же самое.
Даже для масштабирования не обязательно использовать только ffmpeg. Можно использовать, например, VapourSynth (несколько встроенных, плюс jinc, nnedi3, варианты waifu2x и прочего нейросетевого).
Окна свёртки. Импульсные характеристики линейных фильтров с похожими свойствами. Между собой родственниками являются: sinc, lanczos и в меньшей степени jinc. Ещё есть варианты фильтра Ланцоша в взвешивающим окном не sin(x)/x, а Блекмана, Хемминга, Ханна и т. д. См. https://legacy.imagemagick.org/Usage/filter/#windowed
Работают примерно как фильтр Ланцоша, но позволяют оценить другие варианты компромисса между резкостью и «звоном» (уровнем боковых лепестков спектра).
> В ffmpeg другого нет.
https://pastebin.com/iVjMRr7s
Это выхлоп ffmpeg 2.8. В нём указаны следующие фильтры: fast_bilinear, bilinear, bicubic, experimental, neighbor, area, gauss, sinc, lanczos, spline.
Для современного ffmpeg можно посмотреть хотябы исходный код:
https://ffmpeg.org/doxygen/trunk/swscale_8h_source.html#l00057
В нём указаны уже следующие фильтры: fast_bilinear, bilinear, bicubic, experimental, point (он же neighbor), area, gauss, sinc, lanczos, spline. То же самое.
Даже для масштабирования не обязательно использовать только ffmpeg. Можно использовать, например, VapourSynth (несколько встроенных, плюс jinc, nnedi3, варианты waifu2x и прочего нейросетевого).
> И какие ещё родственники?
Окна свёртки. Импульсные характеристики линейных фильтров с похожими свойствами. Между собой родственниками являются: sinc, lanczos и в меньшей степени jinc. Ещё есть варианты фильтра Ланцоша в взвешивающим окном не sin(x)/x, а Блекмана, Хемминга, Ханна и т. д. См. https://legacy.imagemagick.org/Usage/filter/#windowed
Работают примерно как фильтр Ланцоша, но позволяют оценить другие варианты компромисса между резкостью и «звоном» (уровнем боковых лепестков спектра).
>>2998740
Если моё объяснение не устраивает, то можно обратиться к варианту в Википедии или к книжке Ричардсона «Видеокодирование. H.264 и MPEG-4 — стандарты нового поколения».
Если говорить сильно упрощённо, то кодер (H.262, H.263, H.264 или H.265) работает так:
- есть основные задачи алгоритма — дискретное косинусное преобразование (ДКП), поиск и компенсация движения, квантование ДКП-коэффициентов, линеаризация последовательности квантованных ДКП-коэффициентов, формирование потока данных и его энтропийное кодирование;
- ДКП позволяет преобразовать элементы исходного изображения (матрицы 4✕4 или 8✕8 точек растра) из амплитудно-пространственной области в амплитудно-частотную (с вырожденной фазой); такая форма обладает компактностью коэффициентов для сигналов, характерных для естественного происхождения (с выраженными автокорреляционными свойствами) а также выгодна для последующей обработки на предмет снижения избыточности, не воспринимаемой человеческим зрением — в менее заметных высокочастотных составляющих сосредоточено наименьшее количество энергии (в смысле модулей ДКП-коэффициентов) и наименьшее количество воспринимаемой зрением человека информации;
- поиск и компенсация движения позволяют снижать временную избыточность изображения, сопоставляя в разных кадрах исходной последовательности по признаку похожести два (или три для двустороннего предсказания) макроблока (опорный и предсказанный) и подвергая ДКП не два полных блока, а опорный блок и его разность (ошибка предсказания) с предсказанным; т. о. в разностном блоке будет содержаться меньше информации, чем в предсказанном; в потоке для восстановления предсказанного блока будет храниться вектор движения (из разности координат между опорным и предсказанным блоками) и ДКП-коэффициенты ошибки предсказания; макроблок (как единица предсказания и компенсации движения) может состоять из нескольких ДКП-блоков, описание макроблока я опущу, т. к. это только запутает объяснения;
- квантование ДКП-коэффициентов позволяет снижать избыточность восстановленного изображения путём огрубления значений ДКП-коэффициентов и отбрасывания коэффициентов с наименьшим модулем; в результате квантования большая часть коэффициентов вырождается в ноль, а у остальных значительно сужается динамический диапазон, что позволяет кодировать числа меньшим числом бит; в потоке помимо квантованных ДКП-коэффициентов для закодированного кадра и ДКП-блока хранятся квантователь кадра и смещение квантователя блока; при кодировании вычисляется для хранения в потоке частное от матрицы исходных ДКП-коэффициентов и суммы квантоветелей, при восстановлении перед обратным ДКП осуществляется перемножение суммы квантователя кадра и квантователя блока с матрицей ДКП-коэффициентов, последнее необходимо для сохранения энергии в блоке;
- формирование потока данных осуществляется из ранее упомянутых примитивов — квантователей, квантованных и линеаризованных последовательностей ДКП-коэффициентов, векторов движения и ещё кучи более хитрых штуковин; большую часть ширины потока (т. е. частного от количества информации и единицы времени воспроизведения последовательности) занимают квантованные ДКП-коэффициенты, большая часть которых нулевая; поток данных, т. о., имеет автокорреляционные характеристики, располагающие к эффективному (в смысле коэффициента сжатия) энтропийному кодированию, которое и завершает весь процесс работы кодера.
В соответствии с приведёнными выше задачами есть модули программы-кодировщика:
- энтропийный кодировщик и компоновщик потока;
- контроллер ширины потока и значений квантователя;
- модуль поиска и компенсации движения;
- модуль ДКП.
Пользователю разрешено устанавливать параметры для всех модулей, но на близость решения к оптимуму (в смысле противоречия между доступной шириной потока данных и желаемой точностью передачи изображения) наибольшее влияние оказывают параметры контроллера ширины потока и поиска движения.
Вопрос в >>2998728 касался конкретно параметров контроллера ширины потока. Функцией контроллера является определение для каждого закодированного кадра значения квантователя (и ещё квантователей каждого макроблока в кадре, если стандартом и реализацией кодера предусмотрено квантование решетом — trellis). Значение подбирается итерационно в соответствии с критериями:
- указанным значением CRF, которое суть — математическое ожидание нормализованного (в соответствии с поправочными коэффициентами для P- и B-кадров) квантователя кадра;
- доступным (по стандарту) рядом значений квантователей;
- шириной потока закодированного (пробного) фрагмента и соответствующими требованиям стандарта предельными значениями; как правило, предельные значения определены профилем и уровнем в стандарте;
- целевым средним значением ширины потока;
- для двух смежных итераций соотношением между выигрышем в коэффициенте сжатия и изменением показателя искажений — RDO;
- способом предсказания нормализованного значения квантователя следующего кадра.
Основное правило интерпретации результата работы контроллера ширины потока простое: больше квантователь — больше искажений и, весьма вероятно, меньше ширина потока.
Работа контроллера ширины потока определена как оптимизационная задача, основными компонентами которой являются: начальное приближение значения квантователя, функция штрафов. Начальное приближение определяется указанным значением CRF или предсказанным нормализованным значением квантователя следующего кадра. Функцию штрафов можно определить через ряд критериев, который для простоты объяснения я опущу.
Т. к. начальное приближение возможно определить двумя способами, то у большинства контроллеров ширины потока есть две стратегии:
- основанная на CRF — кодер будет стремиться соблюдать постоянное нормализованное значение квантователя кадра (определённое через указанное значение CRF), пиковые отклонения для которого допустимы, например, только при достижении максимальной разрешённой стандартом ширины потока; в составляющие функции штрафов будет добавлен критерий чебышевского (т. е. абсолютного линейного) отклонения значений квантователя;
- основанные на ширине потока (с постоянной шириной потока, или со средней шириной потока) — для постоянной ширины потока кодер будет подбирать такое значение квантователей, чтобы ширина потока не превышала наперёд установленное значение; для достижения средней ширины потока кодер будет подбирать на первом (или единственном проходе) начальные значения квантователей путём предсказания на короткой дистанции (в пределах группы кадров — GOP — или или нескольких групп; ограничивается, как правило, параметров упреждающего анализа — lookahaed frames), а в функцию штрафов будут включены отклонение средней ширины потока от указанного наперёд номинального значения и среднеквадратичное отклонение (СКО) квантователей; что касается второго прохода, то его цель заключается в уточнении субоптимального решения при переходе от небольшого множества анализируемых за раз кадров (lookahaed frames) ко всей кодируемой последовательности целиком.
Теперь по частям.
Дисперсия — кадрат СКО. Здесь указана дополнительная для данного режима и важная часть функции штрафов контроллера ширины потока.
Критерий Чебышёва линейный (а СКО — квадратичный), т. о. он более чувствителен к одиночным большим отклонениям от среднего значения. Такие отклонения получают больший штраф, а кодер, соответственно, будет стремиться избежать такого решения.
В стандартах H.262 и H.264, например, приведены ряд профилей и уровней, которым должны соответствовать кодер, декодер и поток данных. Уровни различаются целевым применением и соответствующими ограничениями на разнообразие примитивов, количество примитивов в единице потока, пределами ширины потока и предельными параметрами исходных последовательностей.
> Что это значит?
Если моё объяснение не устраивает, то можно обратиться к варианту в Википедии или к книжке Ричардсона «Видеокодирование. H.264 и MPEG-4 — стандарты нового поколения».
Если говорить сильно упрощённо, то кодер (H.262, H.263, H.264 или H.265) работает так:
- есть основные задачи алгоритма — дискретное косинусное преобразование (ДКП), поиск и компенсация движения, квантование ДКП-коэффициентов, линеаризация последовательности квантованных ДКП-коэффициентов, формирование потока данных и его энтропийное кодирование;
- ДКП позволяет преобразовать элементы исходного изображения (матрицы 4✕4 или 8✕8 точек растра) из амплитудно-пространственной области в амплитудно-частотную (с вырожденной фазой); такая форма обладает компактностью коэффициентов для сигналов, характерных для естественного происхождения (с выраженными автокорреляционными свойствами) а также выгодна для последующей обработки на предмет снижения избыточности, не воспринимаемой человеческим зрением — в менее заметных высокочастотных составляющих сосредоточено наименьшее количество энергии (в смысле модулей ДКП-коэффициентов) и наименьшее количество воспринимаемой зрением человека информации;
- поиск и компенсация движения позволяют снижать временную избыточность изображения, сопоставляя в разных кадрах исходной последовательности по признаку похожести два (или три для двустороннего предсказания) макроблока (опорный и предсказанный) и подвергая ДКП не два полных блока, а опорный блок и его разность (ошибка предсказания) с предсказанным; т. о. в разностном блоке будет содержаться меньше информации, чем в предсказанном; в потоке для восстановления предсказанного блока будет храниться вектор движения (из разности координат между опорным и предсказанным блоками) и ДКП-коэффициенты ошибки предсказания; макроблок (как единица предсказания и компенсации движения) может состоять из нескольких ДКП-блоков, описание макроблока я опущу, т. к. это только запутает объяснения;
- квантование ДКП-коэффициентов позволяет снижать избыточность восстановленного изображения путём огрубления значений ДКП-коэффициентов и отбрасывания коэффициентов с наименьшим модулем; в результате квантования большая часть коэффициентов вырождается в ноль, а у остальных значительно сужается динамический диапазон, что позволяет кодировать числа меньшим числом бит; в потоке помимо квантованных ДКП-коэффициентов для закодированного кадра и ДКП-блока хранятся квантователь кадра и смещение квантователя блока; при кодировании вычисляется для хранения в потоке частное от матрицы исходных ДКП-коэффициентов и суммы квантоветелей, при восстановлении перед обратным ДКП осуществляется перемножение суммы квантователя кадра и квантователя блока с матрицей ДКП-коэффициентов, последнее необходимо для сохранения энергии в блоке;
- формирование потока данных осуществляется из ранее упомянутых примитивов — квантователей, квантованных и линеаризованных последовательностей ДКП-коэффициентов, векторов движения и ещё кучи более хитрых штуковин; большую часть ширины потока (т. е. частного от количества информации и единицы времени воспроизведения последовательности) занимают квантованные ДКП-коэффициенты, большая часть которых нулевая; поток данных, т. о., имеет автокорреляционные характеристики, располагающие к эффективному (в смысле коэффициента сжатия) энтропийному кодированию, которое и завершает весь процесс работы кодера.
В соответствии с приведёнными выше задачами есть модули программы-кодировщика:
- энтропийный кодировщик и компоновщик потока;
- контроллер ширины потока и значений квантователя;
- модуль поиска и компенсации движения;
- модуль ДКП.
Пользователю разрешено устанавливать параметры для всех модулей, но на близость решения к оптимуму (в смысле противоречия между доступной шириной потока данных и желаемой точностью передачи изображения) наибольшее влияние оказывают параметры контроллера ширины потока и поиска движения.
Вопрос в >>2998728 касался конкретно параметров контроллера ширины потока. Функцией контроллера является определение для каждого закодированного кадра значения квантователя (и ещё квантователей каждого макроблока в кадре, если стандартом и реализацией кодера предусмотрено квантование решетом — trellis). Значение подбирается итерационно в соответствии с критериями:
- указанным значением CRF, которое суть — математическое ожидание нормализованного (в соответствии с поправочными коэффициентами для P- и B-кадров) квантователя кадра;
- доступным (по стандарту) рядом значений квантователей;
- шириной потока закодированного (пробного) фрагмента и соответствующими требованиям стандарта предельными значениями; как правило, предельные значения определены профилем и уровнем в стандарте;
- целевым средним значением ширины потока;
- для двух смежных итераций соотношением между выигрышем в коэффициенте сжатия и изменением показателя искажений — RDO;
- способом предсказания нормализованного значения квантователя следующего кадра.
Основное правило интерпретации результата работы контроллера ширины потока простое: больше квантователь — больше искажений и, весьма вероятно, меньше ширина потока.
Работа контроллера ширины потока определена как оптимизационная задача, основными компонентами которой являются: начальное приближение значения квантователя, функция штрафов. Начальное приближение определяется указанным значением CRF или предсказанным нормализованным значением квантователя следующего кадра. Функцию штрафов можно определить через ряд критериев, который для простоты объяснения я опущу.
Т. к. начальное приближение возможно определить двумя способами, то у большинства контроллеров ширины потока есть две стратегии:
- основанная на CRF — кодер будет стремиться соблюдать постоянное нормализованное значение квантователя кадра (определённое через указанное значение CRF), пиковые отклонения для которого допустимы, например, только при достижении максимальной разрешённой стандартом ширины потока; в составляющие функции штрафов будет добавлен критерий чебышевского (т. е. абсолютного линейного) отклонения значений квантователя;
- основанные на ширине потока (с постоянной шириной потока, или со средней шириной потока) — для постоянной ширины потока кодер будет подбирать такое значение квантователей, чтобы ширина потока не превышала наперёд установленное значение; для достижения средней ширины потока кодер будет подбирать на первом (или единственном проходе) начальные значения квантователей путём предсказания на короткой дистанции (в пределах группы кадров — GOP — или или нескольких групп; ограничивается, как правило, параметров упреждающего анализа — lookahaed frames), а в функцию штрафов будут включены отклонение средней ширины потока от указанного наперёд номинального значения и среднеквадратичное отклонение (СКО) квантователей; что касается второго прохода, то его цель заключается в уточнении субоптимального решения при переходе от небольшого множества анализируемых за раз кадров (lookahaed frames) ко всей кодируемой последовательности целиком.
Теперь по частям.
> малой дисперсии квантователя
Дисперсия — кадрат СКО. Здесь указана дополнительная для данного режима и важная часть функции штрафов контроллера ширины потока.
> удерживает малые отклонения квантователя (по Чебышëву)
Критерий Чебышёва линейный (а СКО — квадратичный), т. о. он более чувствителен к одиночным большим отклонениям от среднего значения. Такие отклонения получают больший штраф, а кодер, соответственно, будет стремиться избежать такого решения.
> предельных характеристиках потока, определëнных для профиля и уровня
В стандартах H.262 и H.264, например, приведены ряд профилей и уровней, которым должны соответствовать кодер, декодер и поток данных. Уровни различаются целевым применением и соответствующими ограничениями на разнообразие примитивов, количество примитивов в единице потока, пределами ширины потока и предельными параметрами исходных последовательностей.
>>2998740
Если моё объяснение не устраивает, то можно обратиться к варианту в Википедии или к книжке Ричардсона «Видеокодирование. H.264 и MPEG-4 — стандарты нового поколения».
Если говорить сильно упрощённо, то кодер (H.262, H.263, H.264 или H.265) работает так:
- есть основные задачи алгоритма — дискретное косинусное преобразование (ДКП), поиск и компенсация движения, квантование ДКП-коэффициентов, линеаризация последовательности квантованных ДКП-коэффициентов, формирование потока данных и его энтропийное кодирование;
- ДКП позволяет преобразовать элементы исходного изображения (матрицы 4✕4 или 8✕8 точек растра) из амплитудно-пространственной области в амплитудно-частотную (с вырожденной фазой); такая форма обладает компактностью коэффициентов для сигналов, характерных для естественного происхождения (с выраженными автокорреляционными свойствами) а также выгодна для последующей обработки на предмет снижения избыточности, не воспринимаемой человеческим зрением — в менее заметных высокочастотных составляющих сосредоточено наименьшее количество энергии (в смысле модулей ДКП-коэффициентов) и наименьшее количество воспринимаемой зрением человека информации;
- поиск и компенсация движения позволяют снижать временную избыточность изображения, сопоставляя в разных кадрах исходной последовательности по признаку похожести два (или три для двустороннего предсказания) макроблока (опорный и предсказанный) и подвергая ДКП не два полных блока, а опорный блок и его разность (ошибка предсказания) с предсказанным; т. о. в разностном блоке будет содержаться меньше информации, чем в предсказанном; в потоке для восстановления предсказанного блока будет храниться вектор движения (из разности координат между опорным и предсказанным блоками) и ДКП-коэффициенты ошибки предсказания; макроблок (как единица предсказания и компенсации движения) может состоять из нескольких ДКП-блоков, описание макроблока я опущу, т. к. это только запутает объяснения;
- квантование ДКП-коэффициентов позволяет снижать избыточность восстановленного изображения путём огрубления значений ДКП-коэффициентов и отбрасывания коэффициентов с наименьшим модулем; в результате квантования большая часть коэффициентов вырождается в ноль, а у остальных значительно сужается динамический диапазон, что позволяет кодировать числа меньшим числом бит; в потоке помимо квантованных ДКП-коэффициентов для закодированного кадра и ДКП-блока хранятся квантователь кадра и смещение квантователя блока; при кодировании вычисляется для хранения в потоке частное от матрицы исходных ДКП-коэффициентов и суммы квантоветелей, при восстановлении перед обратным ДКП осуществляется перемножение суммы квантователя кадра и квантователя блока с матрицей ДКП-коэффициентов, последнее необходимо для сохранения энергии в блоке;
- формирование потока данных осуществляется из ранее упомянутых примитивов — квантователей, квантованных и линеаризованных последовательностей ДКП-коэффициентов, векторов движения и ещё кучи более хитрых штуковин; большую часть ширины потока (т. е. частного от количества информации и единицы времени воспроизведения последовательности) занимают квантованные ДКП-коэффициенты, большая часть которых нулевая; поток данных, т. о., имеет автокорреляционные характеристики, располагающие к эффективному (в смысле коэффициента сжатия) энтропийному кодированию, которое и завершает весь процесс работы кодера.
В соответствии с приведёнными выше задачами есть модули программы-кодировщика:
- энтропийный кодировщик и компоновщик потока;
- контроллер ширины потока и значений квантователя;
- модуль поиска и компенсации движения;
- модуль ДКП.
Пользователю разрешено устанавливать параметры для всех модулей, но на близость решения к оптимуму (в смысле противоречия между доступной шириной потока данных и желаемой точностью передачи изображения) наибольшее влияние оказывают параметры контроллера ширины потока и поиска движения.
Вопрос в >>2998728 касался конкретно параметров контроллера ширины потока. Функцией контроллера является определение для каждого закодированного кадра значения квантователя (и ещё квантователей каждого макроблока в кадре, если стандартом и реализацией кодера предусмотрено квантование решетом — trellis). Значение подбирается итерационно в соответствии с критериями:
- указанным значением CRF, которое суть — математическое ожидание нормализованного (в соответствии с поправочными коэффициентами для P- и B-кадров) квантователя кадра;
- доступным (по стандарту) рядом значений квантователей;
- шириной потока закодированного (пробного) фрагмента и соответствующими требованиям стандарта предельными значениями; как правило, предельные значения определены профилем и уровнем в стандарте;
- целевым средним значением ширины потока;
- для двух смежных итераций соотношением между выигрышем в коэффициенте сжатия и изменением показателя искажений — RDO;
- способом предсказания нормализованного значения квантователя следующего кадра.
Основное правило интерпретации результата работы контроллера ширины потока простое: больше квантователь — больше искажений и, весьма вероятно, меньше ширина потока.
Работа контроллера ширины потока определена как оптимизационная задача, основными компонентами которой являются: начальное приближение значения квантователя, функция штрафов. Начальное приближение определяется указанным значением CRF или предсказанным нормализованным значением квантователя следующего кадра. Функцию штрафов можно определить через ряд критериев, который для простоты объяснения я опущу.
Т. к. начальное приближение возможно определить двумя способами, то у большинства контроллеров ширины потока есть две стратегии:
- основанная на CRF — кодер будет стремиться соблюдать постоянное нормализованное значение квантователя кадра (определённое через указанное значение CRF), пиковые отклонения для которого допустимы, например, только при достижении максимальной разрешённой стандартом ширины потока; в составляющие функции штрафов будет добавлен критерий чебышевского (т. е. абсолютного линейного) отклонения значений квантователя;
- основанные на ширине потока (с постоянной шириной потока, или со средней шириной потока) — для постоянной ширины потока кодер будет подбирать такое значение квантователей, чтобы ширина потока не превышала наперёд установленное значение; для достижения средней ширины потока кодер будет подбирать на первом (или единственном проходе) начальные значения квантователей путём предсказания на короткой дистанции (в пределах группы кадров — GOP — или или нескольких групп; ограничивается, как правило, параметров упреждающего анализа — lookahaed frames), а в функцию штрафов будут включены отклонение средней ширины потока от указанного наперёд номинального значения и среднеквадратичное отклонение (СКО) квантователей; что касается второго прохода, то его цель заключается в уточнении субоптимального решения при переходе от небольшого множества анализируемых за раз кадров (lookahaed frames) ко всей кодируемой последовательности целиком.
Теперь по частям.
Дисперсия — кадрат СКО. Здесь указана дополнительная для данного режима и важная часть функции штрафов контроллера ширины потока.
Критерий Чебышёва линейный (а СКО — квадратичный), т. о. он более чувствителен к одиночным большим отклонениям от среднего значения. Такие отклонения получают больший штраф, а кодер, соответственно, будет стремиться избежать такого решения.
В стандартах H.262 и H.264, например, приведены ряд профилей и уровней, которым должны соответствовать кодер, декодер и поток данных. Уровни различаются целевым применением и соответствующими ограничениями на разнообразие примитивов, количество примитивов в единице потока, пределами ширины потока и предельными параметрами исходных последовательностей.
> Что это значит?
Если моё объяснение не устраивает, то можно обратиться к варианту в Википедии или к книжке Ричардсона «Видеокодирование. H.264 и MPEG-4 — стандарты нового поколения».
Если говорить сильно упрощённо, то кодер (H.262, H.263, H.264 или H.265) работает так:
- есть основные задачи алгоритма — дискретное косинусное преобразование (ДКП), поиск и компенсация движения, квантование ДКП-коэффициентов, линеаризация последовательности квантованных ДКП-коэффициентов, формирование потока данных и его энтропийное кодирование;
- ДКП позволяет преобразовать элементы исходного изображения (матрицы 4✕4 или 8✕8 точек растра) из амплитудно-пространственной области в амплитудно-частотную (с вырожденной фазой); такая форма обладает компактностью коэффициентов для сигналов, характерных для естественного происхождения (с выраженными автокорреляционными свойствами) а также выгодна для последующей обработки на предмет снижения избыточности, не воспринимаемой человеческим зрением — в менее заметных высокочастотных составляющих сосредоточено наименьшее количество энергии (в смысле модулей ДКП-коэффициентов) и наименьшее количество воспринимаемой зрением человека информации;
- поиск и компенсация движения позволяют снижать временную избыточность изображения, сопоставляя в разных кадрах исходной последовательности по признаку похожести два (или три для двустороннего предсказания) макроблока (опорный и предсказанный) и подвергая ДКП не два полных блока, а опорный блок и его разность (ошибка предсказания) с предсказанным; т. о. в разностном блоке будет содержаться меньше информации, чем в предсказанном; в потоке для восстановления предсказанного блока будет храниться вектор движения (из разности координат между опорным и предсказанным блоками) и ДКП-коэффициенты ошибки предсказания; макроблок (как единица предсказания и компенсации движения) может состоять из нескольких ДКП-блоков, описание макроблока я опущу, т. к. это только запутает объяснения;
- квантование ДКП-коэффициентов позволяет снижать избыточность восстановленного изображения путём огрубления значений ДКП-коэффициентов и отбрасывания коэффициентов с наименьшим модулем; в результате квантования большая часть коэффициентов вырождается в ноль, а у остальных значительно сужается динамический диапазон, что позволяет кодировать числа меньшим числом бит; в потоке помимо квантованных ДКП-коэффициентов для закодированного кадра и ДКП-блока хранятся квантователь кадра и смещение квантователя блока; при кодировании вычисляется для хранения в потоке частное от матрицы исходных ДКП-коэффициентов и суммы квантоветелей, при восстановлении перед обратным ДКП осуществляется перемножение суммы квантователя кадра и квантователя блока с матрицей ДКП-коэффициентов, последнее необходимо для сохранения энергии в блоке;
- формирование потока данных осуществляется из ранее упомянутых примитивов — квантователей, квантованных и линеаризованных последовательностей ДКП-коэффициентов, векторов движения и ещё кучи более хитрых штуковин; большую часть ширины потока (т. е. частного от количества информации и единицы времени воспроизведения последовательности) занимают квантованные ДКП-коэффициенты, большая часть которых нулевая; поток данных, т. о., имеет автокорреляционные характеристики, располагающие к эффективному (в смысле коэффициента сжатия) энтропийному кодированию, которое и завершает весь процесс работы кодера.
В соответствии с приведёнными выше задачами есть модули программы-кодировщика:
- энтропийный кодировщик и компоновщик потока;
- контроллер ширины потока и значений квантователя;
- модуль поиска и компенсации движения;
- модуль ДКП.
Пользователю разрешено устанавливать параметры для всех модулей, но на близость решения к оптимуму (в смысле противоречия между доступной шириной потока данных и желаемой точностью передачи изображения) наибольшее влияние оказывают параметры контроллера ширины потока и поиска движения.
Вопрос в >>2998728 касался конкретно параметров контроллера ширины потока. Функцией контроллера является определение для каждого закодированного кадра значения квантователя (и ещё квантователей каждого макроблока в кадре, если стандартом и реализацией кодера предусмотрено квантование решетом — trellis). Значение подбирается итерационно в соответствии с критериями:
- указанным значением CRF, которое суть — математическое ожидание нормализованного (в соответствии с поправочными коэффициентами для P- и B-кадров) квантователя кадра;
- доступным (по стандарту) рядом значений квантователей;
- шириной потока закодированного (пробного) фрагмента и соответствующими требованиям стандарта предельными значениями; как правило, предельные значения определены профилем и уровнем в стандарте;
- целевым средним значением ширины потока;
- для двух смежных итераций соотношением между выигрышем в коэффициенте сжатия и изменением показателя искажений — RDO;
- способом предсказания нормализованного значения квантователя следующего кадра.
Основное правило интерпретации результата работы контроллера ширины потока простое: больше квантователь — больше искажений и, весьма вероятно, меньше ширина потока.
Работа контроллера ширины потока определена как оптимизационная задача, основными компонентами которой являются: начальное приближение значения квантователя, функция штрафов. Начальное приближение определяется указанным значением CRF или предсказанным нормализованным значением квантователя следующего кадра. Функцию штрафов можно определить через ряд критериев, который для простоты объяснения я опущу.
Т. к. начальное приближение возможно определить двумя способами, то у большинства контроллеров ширины потока есть две стратегии:
- основанная на CRF — кодер будет стремиться соблюдать постоянное нормализованное значение квантователя кадра (определённое через указанное значение CRF), пиковые отклонения для которого допустимы, например, только при достижении максимальной разрешённой стандартом ширины потока; в составляющие функции штрафов будет добавлен критерий чебышевского (т. е. абсолютного линейного) отклонения значений квантователя;
- основанные на ширине потока (с постоянной шириной потока, или со средней шириной потока) — для постоянной ширины потока кодер будет подбирать такое значение квантователей, чтобы ширина потока не превышала наперёд установленное значение; для достижения средней ширины потока кодер будет подбирать на первом (или единственном проходе) начальные значения квантователей путём предсказания на короткой дистанции (в пределах группы кадров — GOP — или или нескольких групп; ограничивается, как правило, параметров упреждающего анализа — lookahaed frames), а в функцию штрафов будут включены отклонение средней ширины потока от указанного наперёд номинального значения и среднеквадратичное отклонение (СКО) квантователей; что касается второго прохода, то его цель заключается в уточнении субоптимального решения при переходе от небольшого множества анализируемых за раз кадров (lookahaed frames) ко всей кодируемой последовательности целиком.
Теперь по частям.
> малой дисперсии квантователя
Дисперсия — кадрат СКО. Здесь указана дополнительная для данного режима и важная часть функции штрафов контроллера ширины потока.
> удерживает малые отклонения квантователя (по Чебышëву)
Критерий Чебышёва линейный (а СКО — квадратичный), т. о. он более чувствителен к одиночным большим отклонениям от среднего значения. Такие отклонения получают больший штраф, а кодер, соответственно, будет стремиться избежать такого решения.
> предельных характеристиках потока, определëнных для профиля и уровня
В стандартах H.262 и H.264, например, приведены ряд профилей и уровней, которым должны соответствовать кодер, декодер и поток данных. Уровни различаются целевым применением и соответствующими ограничениями на разнообразие примитивов, количество примитивов в единице потока, пределами ширины потока и предельными параметрами исходных последовательностей.
>>2999207
Здесь ошибка закралась.
Требуются пояснения. Я спутал два разных инструмента: инструмент ROI стандарта H.264 и инструмент кодера — trellis R-D quantization. Последнее является техникой оптимизации при квантовании ДКП-коэффициентов в пределах макроблока.
А для ROI (region-of-interest) действительно можно определить отдельные параметры квантования.
> и ещё квантователей каждого макроблока в кадре, если стандартом и реализацией кодера предусмотрено квантование решетом — trellis
Здесь ошибка закралась.
Требуются пояснения. Я спутал два разных инструмента: инструмент ROI стандарта H.264 и инструмент кодера — trellis R-D quantization. Последнее является техникой оптимизации при квантовании ДКП-коэффициентов в пределах макроблока.
А для ROI (region-of-interest) действительно можно определить отдельные параметры квантования.
>>2998732
а если у меня много разных частот кадров
есть 23.97 24 29.97 30 50 60
к какой частоту лучше из привести? или можно выбирать любую, так как в любом случае получится одинаково плохо?
а если у меня много разных частот кадров
есть 23.97 24 29.97 30 50 60
к какой частоту лучше из привести? или можно выбирать любую, так как в любом случае получится одинаково плохо?
>>2999726
К наибольшей, желательно кратной всем перечисленным. К наибольшей приводим затем, что-бы твои 60 fps не потерялись в условных 30.
К наибольшей, желательно кратной всем перечисленным. К наибольшей приводим затем, что-бы твои 60 fps не потерялись в условных 30.
>>2999788
В описанном тобой ранее случае искажений всё равно не избежать, так как там у тебя надо склеить и 24 fps и 24 000 / 1001 fps, и кратную частоту кадров для них всех хуй подберешь.
Хуйня у тебя будет. Ближайшее кратное к 24 000 / 1001 fps будет 48 000 / 1001, оно же 47.95 fps.
В описанном тобой ранее случае искажений всё равно не избежать, так как там у тебя надо склеить и 24 fps и 24 000 / 1001 fps, и кратную частоту кадров для них всех хуй подберешь.
> что будет, если я буду конвертировать 23.97 в 60?
Хуйня у тебя будет. Ближайшее кратное к 24 000 / 1001 fps будет 48 000 / 1001, оно же 47.95 fps.
>>2999726
Допустим, целевая у нас будет 60. Обратной совместимости с вещательными системами нет, но она, скорее всего, не нужна. Зато под массовый современный монитор годна.
30 -> 60 простым дублированием кадров получится, искажений нет, но и плавности движений нет.
29,97 -> 30 можно сделать небольшим ускорением звука и назначением новой частоты кадров; дальше до 60 дублировать кадры.
23,976 -> 24 можно также сделать ускорением звука.
24 догонять до 30 или 60 можно попробовать каким-нибудь современным интерполятором с поиском и компенсацией движения — через VapourSynth и svpflow1+svpflow2, через Avisynth и FrameRateConverter+MaskTools2+MvTools2, можно через RIFE-нейросетку и VapourSynth.
См.
https://www.svp-team.com/wiki/Manual:SVPflow
https://github.com/mysteryx93/FrameRateConverter
https://github.com/HomeOfVapourSynthEvolution/VapourSynth-RIFE-ncnn-Vulkan
Коммерческие (ну, в смысле, сосвем дорогие) решения тоже стоит рассмотреть. Они чудес, ясное дело, не творят, но разрабы бесплатных и недорогих решений скромно упоминают, что среди коммерческих решений могут достигаться результаты более высокого качества.
> 23.97 24 29.97 30 50 60
Допустим, целевая у нас будет 60. Обратной совместимости с вещательными системами нет, но она, скорее всего, не нужна. Зато под массовый современный монитор годна.
30 -> 60 простым дублированием кадров получится, искажений нет, но и плавности движений нет.
29,97 -> 30 можно сделать небольшим ускорением звука и назначением новой частоты кадров; дальше до 60 дублировать кадры.
23,976 -> 24 можно также сделать ускорением звука.
24 догонять до 30 или 60 можно попробовать каким-нибудь современным интерполятором с поиском и компенсацией движения — через VapourSynth и svpflow1+svpflow2, через Avisynth и FrameRateConverter+MaskTools2+MvTools2, можно через RIFE-нейросетку и VapourSynth.
См.
https://www.svp-team.com/wiki/Manual:SVPflow
https://github.com/mysteryx93/FrameRateConverter
https://github.com/HomeOfVapourSynthEvolution/VapourSynth-RIFE-ncnn-Vulkan
Коммерческие (ну, в смысле, сосвем дорогие) решения тоже стоит рассмотреть. Они чудес, ясное дело, не творят, но разрабы бесплатных и недорогих решений скромно упоминают, что среди коммерческих решений могут достигаться результаты более высокого качества.
С какими параметрами частоты дискретизации и битовой глубины кодировать mp3 во flac, чтобы не потерять в качестве?
>>3003338
В новых версиях то ли баг такой бывает, то ли поддержки уже нет. А в старых прекрасно mp3 импортируется. У меня самого стоят одновременно 13 и 17 версии.
> Sony Vegas
В новых версиях то ли баг такой бывает, то ли поддержки уже нет. А в старых прекрасно mp3 импортируется. У меня самого стоят одновременно 13 и 17 версии.
>>3003338
А если я открою mp3 в редакторе (открылось в 32 bit floating point и 44100 Hz), и пересохраню его через редактор во flac с оригинальной частотой дискретизации (44100) и в 16 бит, то что будет? При экспорте во flac редактор не даёт выставить 32 бит, максимум 24. Но 24 не кратно 32.
>floating-point 32 бита
А если я открою mp3 в редакторе (открылось в 32 bit floating point и 44100 Hz), и пересохраню его через редактор во flac с оригинальной частотой дискретизации (44100) и в 16 бит, то что будет? При экспорте во flac редактор не даёт выставить 32 бит, максимум 24. Но 24 не кратно 32.
Как внести в базу ффмпега аудио библеотеку qaac?
Или как то заставить его использовать из папки
Или как то заставить его использовать из папки
>>3004202
А другие кодеки как там оказались
Мне надо кодировать видео ффмпегом, а аудио qaac, так как встроенный аас говно
Я гуглил и нашел как чел закинул в папку qaac ффмпег библеотеки, но не могу понять как выполнить команды
А другие кодеки как там оказались
Мне надо кодировать видео ффмпегом, а аудио qaac, так как встроенный аас говно
Я гуглил и нашел как чел закинул в папку qaac ффмпег библеотеки, но не могу понять как выполнить команды
кст вп9 кал по сравнению с аш 265
надеюсь скоро введут его поддержу на двач, на других бордах есть
надеюсь скоро введут его поддержу на двач, на других бордах есть
>>3004243
qaac это вообще отдельная библиотека, с зависимостью от QuickTime, её никак не приделаешь к ffmpeg, в ffmpeg за aac вроде fdk-aac отвечает, портированный с андроида.
Собрали их так.
qaac это вообще отдельная библиотека, с зависимостью от QuickTime, её никак не приделаешь к ffmpeg, в ffmpeg за aac вроде fdk-aac отвечает, портированный с андроида.
> А другие кодеки как там оказались
Собрали их так.
>>3004243
От других кодеков есть исходный код, а qaac закрытый. В теории, можно добавить поддержку в ffmpeg через общую dll, но наврядил это кто-то сделает. Fdk примерно такого же качества, только не забудь написать -cutoff 20000. Вот готовый билд, он собирается гитхабом так что вирусы невозможно добавить https://github.com/AnimMouse/ffmpeg-stable-autobuild/releases
Так что или отдельно прогоняй qaac, а потом вставляй файл в ffmpeg, или пользуйся fdk
>>3004244
Не введут, браузеры не поддерживают. Av1 годнота, бесплатный и лучше чем h265
От других кодеков есть исходный код, а qaac закрытый. В теории, можно добавить поддержку в ffmpeg через общую dll, но наврядил это кто-то сделает. Fdk примерно такого же качества, только не забудь написать -cutoff 20000. Вот готовый билд, он собирается гитхабом так что вирусы невозможно добавить https://github.com/AnimMouse/ffmpeg-stable-autobuild/releases
Так что или отдельно прогоняй qaac, а потом вставляй файл в ffmpeg, или пользуйся fdk
>>3004244
Не введут, браузеры не поддерживают. Av1 годнота, бесплатный и лучше чем h265
>>3004296
Не закрытый https://github.com/nu774/qaac/releases просто от эппловских компонентов зависит, в чём проблема аудиодорожку через него прогнать, а видео через ffmpeg я вообще не представляю.
> qaac закрытый
Не закрытый https://github.com/nu774/qaac/releases просто от эппловских компонентов зависит, в чём проблема аудиодорожку через него прогнать, а видео через ffmpeg я вообще не представляю.
у кого-нибудь есть "сделанная" версия энкодера vvc вот отсюда: https://github.com/fraunhoferhhi/vvenc
Там нужно пердолится с visual studio и cmake.
я не хочу visual studio ставить только ради этого
может у кого-то есть скомпиленная версия
Там нужно пердолится с visual studio и cmake.
я не хочу visual studio ставить только ради этого
может у кого-то есть скомпиленная версия
>>3004202
А это тут внезапно не причем.
Клипинг - это такое искажение звуковой волны, из ряда нелинейных искажений, когда усиленный сигнал не влазит в сетку квантования, и вышедшие за пределы сетки отчеты квантуються максимальным или минимальных значением из этой сетки, что и порождает необратимые нелинейные искажения.
При декодировании lossy они появляются из-за того что при lossy кодировании волна кодируеться не точно, возникает как правило на месте отчетов с близкой к максимальной амплитудой. Но есть способ избежать клипирования при декодировании из lossy: декодировать в floating-point формат. И разрядность 32 бита здесь из-за особенностей представления чисел во float, так как точность представления числа в нем нелинейна, и чем больше число -тем меньше точность его записи во float. Потому для корректного представления отчетов с оригинальной глубиной 16 бит до lossy кодирования, 16 разрядного float будет мало, надо переходить на 32-х разрядный.
>>3003926
Не могу ручаться за твой редактор, поэтому позаботься предварительно сделать лимитироване (разновидность компрессии), или нормализацию, что-бы сигнал никогда не превышал уровня 0 Дб.
> Твое ухо даже больше 14 бит не услышит, лол
А это тут внезапно не причем.
Клипинг - это такое искажение звуковой волны, из ряда нелинейных искажений, когда усиленный сигнал не влазит в сетку квантования, и вышедшие за пределы сетки отчеты квантуються максимальным или минимальных значением из этой сетки, что и порождает необратимые нелинейные искажения.
При декодировании lossy они появляются из-за того что при lossy кодировании волна кодируеться не точно, возникает как правило на месте отчетов с близкой к максимальной амплитудой. Но есть способ избежать клипирования при декодировании из lossy: декодировать в floating-point формат. И разрядность 32 бита здесь из-за особенностей представления чисел во float, так как точность представления числа в нем нелинейна, и чем больше число -тем меньше точность его записи во float. Потому для корректного представления отчетов с оригинальной глубиной 16 бит до lossy кодирования, 16 разрядного float будет мало, надо переходить на 32-х разрядный.
>>3003926
Не могу ручаться за твой редактор, поэтому позаботься предварительно сделать лимитироване (разновидность компрессии), или нормализацию, что-бы сигнал никогда не превышал уровня 0 Дб.
>>3004478
Спасибо.
Спасибо.
>>3004556
H.265 не будет в браузерах. Твёрдо и чётко, когда H.264 внедряли ещё не было свободных от патентов альтернатив.
H.265 не будет в браузерах. Твёрдо и чётко, когда H.264 внедряли ещё не было свободных от патентов альтернатив.
92 Кб, 512x481>>3004557
Он как раз и нужен так как жмёт без артефактов хорошо с малым размером файла
> H.265 не будет в браузерах. Твёрдо и чётко
Он как раз и нужен так как жмёт без артефактов хорошо с малым размером файла
>>3002840
Однако, хороший вопрос был.
Я так понимаю, стоит задача привести закодированную звуковую дорогу в вид, понимаемый почти любым видео- или звуковым редактором.
Попробую дать исчерпывающий ответ на вопрос.
Итак,
Я так понимаю, что стоит задача избежать (или минимизировать) дополнительных искажений при восстановлении сигнала.
Стандарт ISO/IEC 11172-3:1993 (тот самый MPEG-1 Layer III) предусматривает (нет на руках учтённой или полной копии стандарта — на страницу и пункт указать не могу) следующие варианты частот дискретизации: 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100 и 48000 Гц.
Вот эти почтенные доны >>3002864>>3003338 правы, когда рекомендуют оригинальную частоту дискретизации сохранить. Разумеется, если целевой формат позволяет (например, некоторые применения не позволяют использовать частоту дискретизации, отличную от 48 кГц).
А сколько это в битах. Для начала скажу, что стандарт ISO/IEC 11172-3:1993 не устанавливает конкретного числового представления восстановленного сигнала. Т. о. можно этот самый MP3 декодировать через обратное модифицированное ДКП хоть в целочисленные выборки, хоть в выборки дробные. Конкретно ffmpeg имеет на этот случай два декодера: https://pastebin.com/act3bafA — mp3 и mp3float. Последний используется по умолчанию. Т. о. во избежание дополнительных ошибок округления, следует использовать (как рекомендовал >>3003338) flt или fltp — https://pastebin.com/YehZeeZ6
Мантисса в дробном числе одинарной точности будет целых 23 бита занимать. Опять же, необходимо иметь в виду, что не все программы поддерживают представление отсчётов звуковых дорожек в дробных числах с плавающей запятой.
Впрочем, если нужна звуковая дорожка с целочисленными отсчётами, то для ffmpeg можно указать целочисленный декодер явно:
$ ffmpeg -c:a mp3 -i input.mp3
Имя декодера указывается ДО имени входного файла.
>>3003338
Не обязательно. Целочисленный декодер должен уметь в нормализацию.
>>3003311
Ну, не все монтажки такие же всеядные как ffmpeg.
>>3003926
https://en.wikipedia.org/wiki/FLAC
Опять же:
$ ffmpeg -h encoder=flac -hide_banner
В памяти будет лежать дробными числами.
Преобразование дробных чисел в целые с округлением.
Однако, хороший вопрос был.
> mp3 во flac
Я так понимаю, стоит задача привести закодированную звуковую дорогу в вид, понимаемый почти любым видео- или звуковым редактором.
Попробую дать исчерпывающий ответ на вопрос.
Итак,
> чтобы не потерять в качестве
Я так понимаю, что стоит задача избежать (или минимизировать) дополнительных искажений при восстановлении сигнала.
> частоты дискретизации
Стандарт ISO/IEC 11172-3:1993 (тот самый MPEG-1 Layer III) предусматривает (нет на руках учтённой или полной копии стандарта — на страницу и пункт указать не могу) следующие варианты частот дискретизации: 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100 и 48000 Гц.
Вот эти почтенные доны >>3002864>>3003338 правы, когда рекомендуют оригинальную частоту дискретизации сохранить. Разумеется, если целевой формат позволяет (например, некоторые применения не позволяют использовать частоту дискретизации, отличную от 48 кГц).
> sample_fmt s16
> floating-point 32
А сколько это в битах. Для начала скажу, что стандарт ISO/IEC 11172-3:1993 не устанавливает конкретного числового представления восстановленного сигнала. Т. о. можно этот самый MP3 декодировать через обратное модифицированное ДКП хоть в целочисленные выборки, хоть в выборки дробные. Конкретно ffmpeg имеет на этот случай два декодера: https://pastebin.com/act3bafA — mp3 и mp3float. Последний используется по умолчанию. Т. о. во избежание дополнительных ошибок округления, следует использовать (как рекомендовал >>3003338) flt или fltp — https://pastebin.com/YehZeeZ6
Мантисса в дробном числе одинарной точности будет целых 23 бита занимать. Опять же, необходимо иметь в виду, что не все программы поддерживают представление отсчётов звуковых дорожек в дробных числах с плавающей запятой.
Впрочем, если нужна звуковая дорожка с целочисленными отсчётами, то для ffmpeg можно указать целочисленный декодер явно:
$ ffmpeg -c:a mp3 -i input.mp3
Имя декодера указывается ДО имени входного файла.
>>3003338
> Здравствуй клипинг
Не обязательно. Целочисленный декодер должен уметь в нормализацию.
>>3003311
Ну, не все монтажки такие же всеядные как ffmpeg.
>>3003926
https://en.wikipedia.org/wiki/FLAC
> The FLAC format supports only integer samples, not floating-point.
Опять же:
$ ffmpeg -h encoder=flac -hide_banner
> А если я открою mp3 в редакторе (открылось в 32 bit floating point и 44100 Hz)
В памяти будет лежать дробными числами.
> пересохраню его через редактор во flac с оригинальной частотой дискретизации (44100) и...
Преобразование дробных чисел в целые с округлением.
>>3002840
Однако, хороший вопрос был.
Я так понимаю, стоит задача привести закодированную звуковую дорогу в вид, понимаемый почти любым видео- или звуковым редактором.
Попробую дать исчерпывающий ответ на вопрос.
Итак,
Я так понимаю, что стоит задача избежать (или минимизировать) дополнительных искажений при восстановлении сигнала.
Стандарт ISO/IEC 11172-3:1993 (тот самый MPEG-1 Layer III) предусматривает (нет на руках учтённой или полной копии стандарта — на страницу и пункт указать не могу) следующие варианты частот дискретизации: 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100 и 48000 Гц.
Вот эти почтенные доны >>3002864>>3003338 правы, когда рекомендуют оригинальную частоту дискретизации сохранить. Разумеется, если целевой формат позволяет (например, некоторые применения не позволяют использовать частоту дискретизации, отличную от 48 кГц).
А сколько это в битах. Для начала скажу, что стандарт ISO/IEC 11172-3:1993 не устанавливает конкретного числового представления восстановленного сигнала. Т. о. можно этот самый MP3 декодировать через обратное модифицированное ДКП хоть в целочисленные выборки, хоть в выборки дробные. Конкретно ffmpeg имеет на этот случай два декодера: https://pastebin.com/act3bafA — mp3 и mp3float. Последний используется по умолчанию. Т. о. во избежание дополнительных ошибок округления, следует использовать (как рекомендовал >>3003338) flt или fltp — https://pastebin.com/YehZeeZ6
Мантисса в дробном числе одинарной точности будет целых 23 бита занимать. Опять же, необходимо иметь в виду, что не все программы поддерживают представление отсчётов звуковых дорожек в дробных числах с плавающей запятой.
Впрочем, если нужна звуковая дорожка с целочисленными отсчётами, то для ffmpeg можно указать целочисленный декодер явно:
$ ffmpeg -c:a mp3 -i input.mp3
Имя декодера указывается ДО имени входного файла.
>>3003338
Не обязательно. Целочисленный декодер должен уметь в нормализацию.
>>3003311
Ну, не все монтажки такие же всеядные как ffmpeg.
>>3003926
https://en.wikipedia.org/wiki/FLAC
Опять же:
$ ffmpeg -h encoder=flac -hide_banner
В памяти будет лежать дробными числами.
Преобразование дробных чисел в целые с округлением.
Однако, хороший вопрос был.
> mp3 во flac
Я так понимаю, стоит задача привести закодированную звуковую дорогу в вид, понимаемый почти любым видео- или звуковым редактором.
Попробую дать исчерпывающий ответ на вопрос.
Итак,
> чтобы не потерять в качестве
Я так понимаю, что стоит задача избежать (или минимизировать) дополнительных искажений при восстановлении сигнала.
> частоты дискретизации
Стандарт ISO/IEC 11172-3:1993 (тот самый MPEG-1 Layer III) предусматривает (нет на руках учтённой или полной копии стандарта — на страницу и пункт указать не могу) следующие варианты частот дискретизации: 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100 и 48000 Гц.
Вот эти почтенные доны >>3002864>>3003338 правы, когда рекомендуют оригинальную частоту дискретизации сохранить. Разумеется, если целевой формат позволяет (например, некоторые применения не позволяют использовать частоту дискретизации, отличную от 48 кГц).
> sample_fmt s16
> floating-point 32
А сколько это в битах. Для начала скажу, что стандарт ISO/IEC 11172-3:1993 не устанавливает конкретного числового представления восстановленного сигнала. Т. о. можно этот самый MP3 декодировать через обратное модифицированное ДКП хоть в целочисленные выборки, хоть в выборки дробные. Конкретно ffmpeg имеет на этот случай два декодера: https://pastebin.com/act3bafA — mp3 и mp3float. Последний используется по умолчанию. Т. о. во избежание дополнительных ошибок округления, следует использовать (как рекомендовал >>3003338) flt или fltp — https://pastebin.com/YehZeeZ6
Мантисса в дробном числе одинарной точности будет целых 23 бита занимать. Опять же, необходимо иметь в виду, что не все программы поддерживают представление отсчётов звуковых дорожек в дробных числах с плавающей запятой.
Впрочем, если нужна звуковая дорожка с целочисленными отсчётами, то для ffmpeg можно указать целочисленный декодер явно:
$ ffmpeg -c:a mp3 -i input.mp3
Имя декодера указывается ДО имени входного файла.
>>3003338
> Здравствуй клипинг
Не обязательно. Целочисленный декодер должен уметь в нормализацию.
>>3003311
Ну, не все монтажки такие же всеядные как ffmpeg.
>>3003926
https://en.wikipedia.org/wiki/FLAC
> The FLAC format supports only integer samples, not floating-point.
Опять же:
$ ffmpeg -h encoder=flac -hide_banner
> А если я открою mp3 в редакторе (открылось в 32 bit floating point и 44100 Hz)
В памяти будет лежать дробными числами.
> пересохраню его через редактор во flac с оригинальной частотой дискретизации (44100) и...
Преобразование дробных чисел в целые с округлением.
>>3004870
Пользователям надо чтобы всё работало само, как у обезьяны, в браузере, без лишних кодеков и скачиваний. Самый популярный браузер - хромиум и Гугл не собирается платить за хевк. За ав1 будущее
Пользователям надо чтобы всё работало само, как у обезьяны, в браузере, без лишних кодеков и скачиваний. Самый популярный браузер - хромиум и Гугл не собирается платить за хевк. За ав1 будущее
>>3004955
Только в браузерах. На всех Blu-Ray носителях 4К фильмы закодированы H.265.
> За ав1 будущее
Только в браузерах. На всех Blu-Ray носителях 4К фильмы закодированы H.265.
>>3004082
Никак. Кодер qaac — это CLI-обёртка для библиотек Яббла.
Если хочется qaac, то берёшь WINE настоящий Шиндовс, ставишь на него библиотечки Яббла, ставишь qaac. Потом, указываешь и тому и другому, что обмен пойдёт через формат ADTS/WAV (обе программы его понимают и умеют правильно записать и прочитать заголовок, что избавит тебя от явного указания расположения каналов, частот дискретизации и всего такого), указываешь, что ffmpeg будет в stdout писать, а qaac будет из stdin читать, собираешь конвейер, кодируешь.
>>3004202
Специалисты по психоакустике в треде — все в Институт им. Фраунгофера!
>>3004243
Свободные программисты понаписали.
Говно у тебя в головушке. А встроенный вполне. Он убогий, да, но вполне. Если не хватает встроенного, то (как уже сообщил >>3004296) есть внешний слинкованный libfdk_aac — полнофункциональный и весьма качественный кодер из libfdk от той самой лаборатории из Института им. Фраунгофера.
Сам по инструкции не можешь элементарный конвейер собрать, а встроенный кодек уже критиковать научился.
>>3004297
Нет никакой проблемы. Берёшь и прогоняешь.
>>3004357
Не мог бы ты предоставить ссылки на источники столь увлекательной информации???
>>3004454
Кстати, да. Тоже часто задаю этот вопрос гражданам с ограниченной вменяемостью.
>>3004457
Это по границам единиц потока. Для видео с компенсацией движения такой единицей будет группа изображений (GOP), для звуковых дорожек будет окно преобразования (frame).
>>3004637
Тоже пишешь пост по секретным документам???
> Как внести в базу ффмпега аудио библеотеку qaac?
Никак. Кодер qaac — это CLI-обёртка для библиотек Яббла.
> как то заставить его использовать из папки
Если хочется qaac, то берёшь WINE настоящий Шиндовс, ставишь на него библиотечки Яббла, ставишь qaac. Потом, указываешь и тому и другому, что обмен пойдёт через формат ADTS/WAV (обе программы его понимают и умеют правильно записать и прочитать заголовок, что избавит тебя от явного указания расположения каналов, частот дискретизации и всего такого), указываешь, что ffmpeg будет в stdout писать, а qaac будет из stdin читать, собираешь конвейер, кодируешь.
>>3004202
>Твое ухо даже больше 14 бит не услышит, лол
Специалисты по психоакустике в треде — все в Институт им. Фраунгофера!
>>3004243
>А другие кодеки как там оказались
Свободные программисты понаписали.
> встроенный аас говно
Говно у тебя в головушке. А встроенный вполне. Он убогий, да, но вполне. Если не хватает встроенного, то (как уже сообщил >>3004296) есть внешний слинкованный libfdk_aac — полнофункциональный и весьма качественный кодер из libfdk от той самой лаборатории из Института им. Фраунгофера.
> Я гуглил и нашел как чел закинул в папку qaac ффмпег библеотеки, но не могу понять как выполнить команды
Сам по инструкции не можешь элементарный конвейер собрать, а встроенный кодек уже критиковать научился.
>>3004297
> в чём проблема аудиодорожку через него прогнать, а видео через ffmpeg я вообще не представляю.
Нет никакой проблемы. Берёшь и прогоняешь.
>>3004357
> При декодировании lossy они появляются из-за того что при lossy кодировании волна кодируеться не точно, возникает как правило на месте отчетов с близкой к максимальной амплитудой. Но есть способ избежать клипирования при декодировании из lossy: декодировать в floating-point формат.
Не мог бы ты предоставить ссылки на источники столь увлекательной информации???
>>3004454
Кстати, да. Тоже часто задаю этот вопрос гражданам с ограниченной вменяемостью.
>>3004457
Это по границам единиц потока. Для видео с компенсацией движения такой единицей будет группа изображений (GOP), для звуковых дорожек будет окно преобразования (frame).
>>3004637
Тоже пишешь пост по секретным документам???
>>3004082
Никак. Кодер qaac — это CLI-обёртка для библиотек Яббла.
Если хочется qaac, то берёшь WINE настоящий Шиндовс, ставишь на него библиотечки Яббла, ставишь qaac. Потом, указываешь и тому и другому, что обмен пойдёт через формат ADTS/WAV (обе программы его понимают и умеют правильно записать и прочитать заголовок, что избавит тебя от явного указания расположения каналов, частот дискретизации и всего такого), указываешь, что ffmpeg будет в stdout писать, а qaac будет из stdin читать, собираешь конвейер, кодируешь.
>>3004202
Специалисты по психоакустике в треде — все в Институт им. Фраунгофера!
>>3004243
Свободные программисты понаписали.
Говно у тебя в головушке. А встроенный вполне. Он убогий, да, но вполне. Если не хватает встроенного, то (как уже сообщил >>3004296) есть внешний слинкованный libfdk_aac — полнофункциональный и весьма качественный кодер из libfdk от той самой лаборатории из Института им. Фраунгофера.
Сам по инструкции не можешь элементарный конвейер собрать, а встроенный кодек уже критиковать научился.
>>3004297
Нет никакой проблемы. Берёшь и прогоняешь.
>>3004357
Не мог бы ты предоставить ссылки на источники столь увлекательной информации???
>>3004454
Кстати, да. Тоже часто задаю этот вопрос гражданам с ограниченной вменяемостью.
>>3004457
Это по границам единиц потока. Для видео с компенсацией движения такой единицей будет группа изображений (GOP), для звуковых дорожек будет окно преобразования (frame).
>>3004637
Тоже пишешь пост по секретным документам???
> Как внести в базу ффмпега аудио библеотеку qaac?
Никак. Кодер qaac — это CLI-обёртка для библиотек Яббла.
> как то заставить его использовать из папки
Если хочется qaac, то берёшь WINE настоящий Шиндовс, ставишь на него библиотечки Яббла, ставишь qaac. Потом, указываешь и тому и другому, что обмен пойдёт через формат ADTS/WAV (обе программы его понимают и умеют правильно записать и прочитать заголовок, что избавит тебя от явного указания расположения каналов, частот дискретизации и всего такого), указываешь, что ffmpeg будет в stdout писать, а qaac будет из stdin читать, собираешь конвейер, кодируешь.
>>3004202
>Твое ухо даже больше 14 бит не услышит, лол
Специалисты по психоакустике в треде — все в Институт им. Фраунгофера!
>>3004243
>А другие кодеки как там оказались
Свободные программисты понаписали.
> встроенный аас говно
Говно у тебя в головушке. А встроенный вполне. Он убогий, да, но вполне. Если не хватает встроенного, то (как уже сообщил >>3004296) есть внешний слинкованный libfdk_aac — полнофункциональный и весьма качественный кодер из libfdk от той самой лаборатории из Института им. Фраунгофера.
> Я гуглил и нашел как чел закинул в папку qaac ффмпег библеотеки, но не могу понять как выполнить команды
Сам по инструкции не можешь элементарный конвейер собрать, а встроенный кодек уже критиковать научился.
>>3004297
> в чём проблема аудиодорожку через него прогнать, а видео через ffmpeg я вообще не представляю.
Нет никакой проблемы. Берёшь и прогоняешь.
>>3004357
> При декодировании lossy они появляются из-за того что при lossy кодировании волна кодируеться не точно, возникает как правило на месте отчетов с близкой к максимальной амплитудой. Но есть способ избежать клипирования при декодировании из lossy: декодировать в floating-point формат.
Не мог бы ты предоставить ссылки на источники столь увлекательной информации???
>>3004454
Кстати, да. Тоже часто задаю этот вопрос гражданам с ограниченной вменяемостью.
>>3004457
Это по границам единиц потока. Для видео с компенсацией движения такой единицей будет группа изображений (GOP), для звуковых дорожек будет окно преобразования (frame).
>>3004637
Тоже пишешь пост по секретным документам???
аноны.
совсем ничего не понимаю в ffmpeg,
пытаюсь соединить много файлов в один видео файл путём такой компанды
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mp4
но получается Non-monotonous DTS
Если использую программу MP4Joiner, то итоговое видео имеет глюки со звуком и изображением
как соединить ролики в один, чтобы не было глюков со звуком и изображением.
перед соединением конвертировал частоту кадров у всех до 60, и разрешение до 1080p
помогите, пожалуйста
совсем ничего не понимаю в ffmpeg,
пытаюсь соединить много файлов в один видео файл путём такой компанды
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mp4
но получается Non-monotonous DTS
Если использую программу MP4Joiner, то итоговое видео имеет глюки со звуком и изображением
как соединить ролики в один, чтобы не было глюков со звуком и изображением.
перед соединением конвертировал частоту кадров у всех до 60, и разрешение до 1080p
помогите, пожалуйста
>>3004974
Все источники помнить не могу, но вот который я еще помню
https://audiophilesoft.ru/publ/my/aimp3_vs_foobar2000/11-1-0-255
Статья старая, те косяки которые там перечислены в AIMP наверно уже подправили.
Вот интересующий фрагмент:
Кроме того, я специально для тебя погуглил, что-бы найти ещё источники.
https://forum.audacityteam.org/viewtopic.php?t=96603
https://audiophilesoft.ru/forum/3-141-1
Ладно, допустим источники недостоверные. Но это можно проверить и самостоятельно (см. пикрелейтед, красные линии - индикатор клиппинга).
> Не мог бы ты предоставить ссылки на источники столь увлекательной информации???
Все источники помнить не могу, но вот который я еще помню
https://audiophilesoft.ru/publ/my/aimp3_vs_foobar2000/11-1-0-255
Статья старая, те косяки которые там перечислены в AIMP наверно уже подправили.
Вот интересующий фрагмент:
> Здесь я хотел бы еще раз вернуться к декодированию. В AIMP поток от декодера идет в формате 16 бит, а следовательно, при наличии превышения уровня в источнике (скажем, MP3), сразу же происходит клиппинг, и никакие лимитеры уж не помогут. У foobar2000 же есть масса методов борьбы с клиппингом — ReplayGain, Advanced Limiter и другие DSP, регулятор громкости. В случае вывода через WASAPI shared (DS) сработает лимитер Windows, или опять же можно воспользоваться занижением громкости для приложения в микшере Windows. AIMP же лишен всех этих возможностей (несмотря на наличие поддержки ReplayGain и ограничителя — всё это сводится на нет из-за декодирования с фиксированной точкой).
Кроме того, я специально для тебя погуглил, что-бы найти ещё источники.
https://forum.audacityteam.org/viewtopic.php?t=96603
> MP3 is an inexact format. If the peak level before encoding is close to 0 dB, then the peak level after encoding may be a little over 0 dB. This is particularly the case if the audio has been heavily limited or compressed. The actual amount of clipping caused by this effect is usually just isolated samples, though there may be a lot of them, so the clipping can look bad while not actually being audible.
https://audiophilesoft.ru/forum/3-141-1
> При кодировании любого файла в lossy формат происходит повышение уровня пиков и чем выбранный битрейт ниже, тем выше этот пик становится. Например при кодировании в MP3 кодером LAME с параметром -V 0 для того, чтобы пиковая громкость не выходила за "0" я нормализую средний трек до -1db. Объясните пожалуйста почему это происходит и необходимо ли с этим бороться? На слух вроде бы не слышно, но если вдруг потребуется провести новое кодирование с этим треком, то что выше "0" не будет учтено при кодировании, если например не нормализовать предварительно MP3 Gain.
> потому что при кодировании происходит квантование составляющих по амплитуде, в итоге получается ошибка квантования, которая может суммироваться и при декодировании сигнал будет иметь большую амплитуду, чем исходный. декодирование lossy - это синтез.
Ладно, допустим источники недостоверные. Но это можно проверить и самостоятельно (см. пикрелейтед, красные линии - индикатор клиппинга).
>>3004974
Все источники помнить не могу, но вот который я еще помню
https://audiophilesoft.ru/publ/my/aimp3_vs_foobar2000/11-1-0-255
Статья старая, те косяки которые там перечислены в AIMP наверно уже подправили.
Вот интересующий фрагмент:
Кроме того, я специально для тебя погуглил, что-бы найти ещё источники.
https://forum.audacityteam.org/viewtopic.php?t=96603
https://audiophilesoft.ru/forum/3-141-1
Ладно, допустим источники недостоверные. Но это можно проверить и самостоятельно (см. пикрелейтед, красные линии - индикатор клиппинга).
> Не мог бы ты предоставить ссылки на источники столь увлекательной информации???
Все источники помнить не могу, но вот который я еще помню
https://audiophilesoft.ru/publ/my/aimp3_vs_foobar2000/11-1-0-255
Статья старая, те косяки которые там перечислены в AIMP наверно уже подправили.
Вот интересующий фрагмент:
> Здесь я хотел бы еще раз вернуться к декодированию. В AIMP поток от декодера идет в формате 16 бит, а следовательно, при наличии превышения уровня в источнике (скажем, MP3), сразу же происходит клиппинг, и никакие лимитеры уж не помогут. У foobar2000 же есть масса методов борьбы с клиппингом — ReplayGain, Advanced Limiter и другие DSP, регулятор громкости. В случае вывода через WASAPI shared (DS) сработает лимитер Windows, или опять же можно воспользоваться занижением громкости для приложения в микшере Windows. AIMP же лишен всех этих возможностей (несмотря на наличие поддержки ReplayGain и ограничителя — всё это сводится на нет из-за декодирования с фиксированной точкой).
Кроме того, я специально для тебя погуглил, что-бы найти ещё источники.
https://forum.audacityteam.org/viewtopic.php?t=96603
> MP3 is an inexact format. If the peak level before encoding is close to 0 dB, then the peak level after encoding may be a little over 0 dB. This is particularly the case if the audio has been heavily limited or compressed. The actual amount of clipping caused by this effect is usually just isolated samples, though there may be a lot of them, so the clipping can look bad while not actually being audible.
https://audiophilesoft.ru/forum/3-141-1
> При кодировании любого файла в lossy формат происходит повышение уровня пиков и чем выбранный битрейт ниже, тем выше этот пик становится. Например при кодировании в MP3 кодером LAME с параметром -V 0 для того, чтобы пиковая громкость не выходила за "0" я нормализую средний трек до -1db. Объясните пожалуйста почему это происходит и необходимо ли с этим бороться? На слух вроде бы не слышно, но если вдруг потребуется провести новое кодирование с этим треком, то что выше "0" не будет учтено при кодировании, если например не нормализовать предварительно MP3 Gain.
> потому что при кодировании происходит квантование составляющих по амплитуде, в итоге получается ошибка квантования, которая может суммироваться и при декодировании сигнал будет иметь большую амплитуду, чем исходный. декодирование lossy - это синтез.
Ладно, допустим источники недостоверные. Но это можно проверить и самостоятельно (см. пикрелейтед, красные линии - индикатор клиппинга).
>>3005079
Основной источник это нетфликс в бра
Основной источник это нетфликс в бра
>>3004974
На аудиофил ру лежит готовая сборка со всеми длл
> Если хочется qaac, то берёшь WINE настоящий Шиндовс, ставишь на него библиотечки Яббла, ставишь qaac
На аудиофил ру лежит готовая сборка со всеми длл
Господа, чо значит 23.976 фпс, что последний кадр в секунде какой то обрезанный хотя мы этого не видим?
>>3005252
Изначально в вещательной системе NTSC была частота кадровой развëртки ровно 60 Гц (60 полей в секунду). При разработке цветного варианта NTSC выяснилось, что частоту следования полей необходимо немного понизить, чтобы сузить полосу сигнала цветовых компонент, и спектры цветовых компонент и звукового сигнала не пересекались. Стала частота следования полей 60000/1001 Гц. А потом благодаря хитрой схеме телекино аналогично пришлось замедлить показ кинофильмов, подготавливаемых к демонстрации в вещательных системах NTSC.
Изначально в вещательной системе NTSC была частота кадровой развëртки ровно 60 Гц (60 полей в секунду). При разработке цветного варианта NTSC выяснилось, что частоту следования полей необходимо немного понизить, чтобы сузить полосу сигнала цветовых компонент, и спектры цветовых компонент и звукового сигнала не пересекались. Стала частота следования полей 60000/1001 Гц. А потом благодаря хитрой схеме телекино аналогично пришлось замедлить показ кинофильмов, подготавливаемых к демонстрации в вещательных системах NTSC.
>>3005113
нашёл вот такое решение.
concat -segment_time_metadata 1 -i file.txt -vf select=concatdec_select -af aselect=concatdec_select,aresample=async=1 out.mp4
вечером попробую
нашёл вот такое решение.
concat -segment_time_metadata 1 -i file.txt -vf select=concatdec_select -af aselect=concatdec_select,aresample=async=1 out.mp4
вечером попробую
>>3005259
https://audiophilesoft.ru/load/coders_utils/qaac/7-1-0-50
Только в ней нет библиотек FLAC, WAV и др, она просто не откроет входные файлы
https://audiophilesoft.ru/load/coders_utils/qaac/7-1-0-50
Только в ней нет библиотек FLAC, WAV и др, она просто не откроет входные файлы
Пацаны объясните кто нибудь ffнубасю что означают вот эти все [0:v] и [1:v]?
Например вот тут:
Например вот тут:
> ffmpeg -i input.mp4 -i image.jpg -filter_complex "[0:v][1:v] overlay=400:200:enable='between(t,0,10)'" -pix_fmt yuv420p -c:a copy output.mp4
>>3005367
Это аргументы, представляющие собой видеопотоки из первого и второго входных файлов.
Это аргументы, представляющие собой видеопотоки из первого и второго входных файлов.
>>2979843 (OP)
О какой хороший тред.
И тут явно сидят спецы по смежной софтине - YOUTUBE-DL
Собсна, вопрос. Давече напердолил скрипт для автоматической подгрузки новых видео с каналов (спасибо 4k video downloader что поломал эту функцию), но как всегда что-то пошло не так.
С начала работы вылезает вот такая вот залупень:
[youtube:tab] Downloading login page
[youtube:tab] Looking up account info
WARNING: Unable to look up account info: HTTP Error 400: Bad Request
Дальше работает, но я незалогиненый. Хотя я про куки не забыл, логин-пароль правильный.
ЧЯДНТ?
О какой хороший тред.
И тут явно сидят спецы по смежной софтине - YOUTUBE-DL
Собсна, вопрос. Давече напердолил скрипт для автоматической подгрузки новых видео с каналов (спасибо 4k video downloader что поломал эту функцию), но как всегда что-то пошло не так.
С начала работы вылезает вот такая вот залупень:
[youtube:tab] Downloading login page
[youtube:tab] Looking up account info
WARNING: Unable to look up account info: HTTP Error 400: Bad Request
Дальше работает, но я незалогиненый. Хотя я про куки не забыл, логин-пароль правильный.
ЧЯДНТ?
>>3005367
FFmpeg может работать с несколькими медиа файлами одновременно. Медиа файл представляет собой контейнер, содержащий медиа потоки.
Каждый файл на входе пронумерован. Нумерация файлов в FFmpeg начинаеться с нуля.
Нумерация потоков также начинаеться с нуля. Но потоки также различаються типом:
аудио-поток: a
графический поток (видео или изображение): v
поток субтитров: s
Потоки каждого типа тоже нумеруються. Если номер не указан, беруться все потоки даного файла или все потоки даного типа.
К чему я всё это расказываю? В FFmpeg есть ключ -map. Он выбирает входной медиа поток для выходного потока. Примеры:
-map 0 - взять все медиапотоки из первого файла
-map 0:0 - взять перный поток из первого файла
-map 0:a - взять все аудиопотоки из первого файла
-map 0:a:1 - взять вторую аудио дорожку из первого файла
-map 0:v:0 -map 0:a -map 1:s - взять первый видеопоток из первого файла, взять все аудиопотоки из первого файла, взять все субтитры из второго файла.
-map 0 -map 1:s - взять все медиапотоки из первого файла, и взять все субтитры из второго файла.
Этот код в фигурных скобках означает то-же, что и аргументы ключа map.
берет все видеопотоки (изображения) из первого и второго файла.
FFmpeg может работать с несколькими медиа файлами одновременно. Медиа файл представляет собой контейнер, содержащий медиа потоки.
Каждый файл на входе пронумерован. Нумерация файлов в FFmpeg начинаеться с нуля.
Нумерация потоков также начинаеться с нуля. Но потоки также различаються типом:
аудио-поток: a
графический поток (видео или изображение): v
поток субтитров: s
Потоки каждого типа тоже нумеруються. Если номер не указан, беруться все потоки даного файла или все потоки даного типа.
К чему я всё это расказываю? В FFmpeg есть ключ -map. Он выбирает входной медиа поток для выходного потока. Примеры:
-map 0 - взять все медиапотоки из первого файла
-map 0:0 - взять перный поток из первого файла
-map 0:a - взять все аудиопотоки из первого файла
-map 0:a:1 - взять вторую аудио дорожку из первого файла
-map 0:v:0 -map 0:a -map 1:s - взять первый видеопоток из первого файла, взять все аудиопотоки из первого файла, взять все субтитры из второго файла.
-map 0 -map 1:s - взять все медиапотоки из первого файла, и взять все субтитры из второго файла.
Этот код в фигурных скобках означает то-же, что и аргументы ключа map.
> [0:v][1:v]
> -map 0:v -map 1:v
берет все видеопотоки (изображения) из первого и второго файла.
Сап, анон
Я тупой
(Гуманитарий)
Напишите скрипт для сабжа чтобы переделать все файлы mp4 в папке из 1080p в 720p
С меня как обычно
Я тупой
(Гуманитарий)
Напишите скрипт для сабжа чтобы переделать все файлы mp4 в папке из 1080p в 720p
С меня как обычно
>>3005501
forfiles /M "c:\papka-name\*.mp4" /C "cmd ffmpeg -i @file -c:v libx264 -vf scale=1920:1080 -c:a aac ..\out\@file-720p.mp4"
вдруг сработает
forfiles /M "c:\papka-name\*.mp4" /C "cmd ffmpeg -i @file -c:v libx264 -vf scale=1920:1080 -c:a aac ..\out\@file-720p.mp4"
вдруг сработает
>>3005506
"C:\Youtube-dl\youtube-dl.exe" --skip-download --usernameex6iFample ANUSgmaim.9l PUNCTUMcoIMOm --password HuyTebeANePassword --cookies "D:\Desktop\Apps\Youtube-dl\youtube.com_cookies.txt" --ignore-errors --no-continue --no-overwrites --download-archive "D:\Desktop\Apps\Youtube-dl\archive.txt" --output "D:\Downloads\Youtube\(title)s.(ext)s" --format "bestvideo[height<=1080]+bestaudio/[height<=1080]" --batch-file "D:\Desktop\Apps\Youtube-dl\Channels.txt" > D:\Desktop\Apps\Youtube-dl\log.txt 2>&1
"C:\Youtube-dl\youtube-dl.exe" --skip-download --username
78 Кб, 1113x641Почему ffplay не работает и как сделать так чтобы работал?
Пытаюсь кропать видео:
выдает: Failed to set value 'crop=1080:800:415:130' for option 'filter:v': Option not found
Приходится ffmpeg'ом, но хочется сразу на результат смотреть.
Пытаюсь кропать видео:
> ffplay -i .\input.mp4 -filter:v "crop=1080:800:415:130" out.mp4
выдает: Failed to set value 'crop=1080:800:415:130' for option 'filter:v': Option not found
Приходится ffmpeg'ом, но хочется сразу на результат смотреть.
>>3005538
блин, ну я точно помню что уже так делал. применял эффект к воспроизведению через ffplay. просто недавно переустановил шиндовс (новый ссд купил, все такое) и чет перестало.
видео в котором чел показывает что такое бывает https://www.youtube.com/watch?v=0CqBRUirGOA
блин, ну я точно помню что уже так делал. применял эффект к воспроизведению через ffplay. просто недавно переустановил шиндовс (новый ссд купил, все такое) и чет перестало.
видео в котором чел показывает что такое бывает https://www.youtube.com/watch?v=0CqBRUirGOA
17 Кб, 663x149>>3005302
к сожалению, когда я добавляю все 338 файлов. они не соединяются
вот какие-то ошибки
но часть пикчи закрыта окном(которое заняято обработкой файлов)
к сожалению, когда я добавляю все 338 файлов. они не соединяются
вот какие-то ошибки
но часть пикчи закрыта окном(которое заняято обработкой файлов)
>>3006326
Скрипт же, батник.
Скрипт же, батник.
>>3006619
Ярлычки там храню, удобно.
Особенно удобно когда в проводнике на стрелочку в строке поиска кликаешь, можно сразу туда перейти.
А ещё удобнее когда так Default App выбираешь.
Ярлычки там храню, удобно.
Особенно удобно когда в проводнике на стрелочку в строке поиска кликаешь, можно сразу туда перейти.
А ещё удобнее когда так Default App выбираешь.
>>3004953
Спасибо за столь развёрнутый ответ.
Получается мне никак не избежать округления, если я хочу использовать flac? Но поскольку
я не потеряю в качестве, верно?
При каких обстоятельствах целочисленный декодер может не уметь в нормализацию? Нормализацию имеет всё достойное современное ПО?
Спасибо за столь развёрнутый ответ.
>Преобразование дробных чисел в целые с округлением.
Получается мне никак не избежать округления, если я хочу использовать flac? Но поскольку
>Целочисленный декодер должен уметь в нормализацию.
я не потеряю в качестве, верно?
При каких обстоятельствах целочисленный декодер может не уметь в нормализацию? Нормализацию имеет всё достойное современное ПО?
>>3004955
Гугл за триллион лет не довел до ума вп9. Ав1 обречён остаться экспериментом.
> За ав1 будущее
Гугл за триллион лет не довел до ума вп9. Ав1 обречён остаться экспериментом.
>>2979843 (OP)
Может вопрос вызовет попоболь у пердоликов, но всё же.
Посоветуйте хороших, годных конвертеров. Сам юзал только Wondershare и FormatFactory, но первый иногда пидорасит папки BD и DVD и вообще надо подбирать версию чтоб не крашилась. Второй вообще годится максимум для конвертирования из видео в mp3.
Может есть что-то более универсальное, кроме сабжа?
Может вопрос вызовет попоболь у пердоликов, но всё же.
Посоветуйте хороших, годных конвертеров. Сам юзал только Wondershare и FormatFactory, но первый иногда пидорасит папки BD и DVD и вообще надо подбирать версию чтоб не крашилась. Второй вообще годится максимум для конвертирования из видео в mp3.
Может есть что-то более универсальное, кроме сабжа?
>>3007387
ждём h.266/vvc
ждём h.266/vvc
>>3007404
ffmpeg'ом конвертируй
нахуй весь этот мусор
> сидит в треде ffmpeg
> спрашивает конвертер
ffmpeg'ом конвертируй
> Wondershare
> FormatFactory
нахуй весь этот мусор
>>3007420
вондершар - это же редактор фильмора э. н больше для вставки свистоперлелок в видосы
формат фактори - не ебу, что это часто слышу.
да. проще всего конверлить через ffmpeg. если ты не знаешь/не хочешь использовать специфичные опции, которые нужно гуглить.
а колдовать и играться с настройками видео можно в XMediaRecode
вондершар - это же редактор фильмора э. н больше для вставки свистоперлелок в видосы
формат фактори - не ебу, что это часто слышу.
да. проще всего конверлить через ffmpeg. если ты не знаешь/не хочешь использовать специфичные опции, которые нужно гуглить.
а колдовать и играться с настройками видео можно в XMediaRecode
>>3007387
Av1 делает огромная куча компаний, даже в текущем виде он уже намного лучше vp9 и немного x265.
Av1 делает огромная куча компаний, даже в текущем виде он уже намного лучше vp9 и немного x265.
>>3007459
Он лучше только в сжатии, в остальном это пососная дичь типа вп9. С учётом времени кодирования, само существование ав1 выглядит как шутка.
Он лучше только в сжатии, в остальном это пососная дичь типа вп9. С учётом времени кодирования, само существование ав1 выглядит как шутка.
>>3007536
Вот через 5 лет и приходи.
Вот через 5 лет и приходи.
Куда вы жмёте hevc?
Давайте по факту. Лично у меня 2 конечной цели сжатия: 2ch с ограничением 20 мб в /b/ и discord с ограничением 8 мб на серверах без бустов. Ни тот, ни другой не поддерживают hevc, вроде потому что на html5 (поправьте), так что выбор у меня из avc и vp9, поэтому я ставлю на ночь vp9 veryslow и иду спать.
Youtube в размере не ограничивает, поэтому если бы я был блоггером, то просто просирался бы большим битрейтом на avc через gpu, благо youtube сам его рекомендует.
Twitch просто ничего кроме avc не поддерживает и до кучи ограничивает битрейт 6 мбит/с, так что у стримеров вопрос не в кодеке, а в железе.
Куда ещё жать-то?
Давайте по факту. Лично у меня 2 конечной цели сжатия: 2ch с ограничением 20 мб в /b/ и discord с ограничением 8 мб на серверах без бустов. Ни тот, ни другой не поддерживают hevc, вроде потому что на html5 (поправьте), так что выбор у меня из avc и vp9, поэтому я ставлю на ночь vp9 veryslow и иду спать.
Youtube в размере не ограничивает, поэтому если бы я был блоггером, то просто просирался бы большим битрейтом на avc через gpu, благо youtube сам его рекомендует.
Twitch просто ничего кроме avc не поддерживает и до кучи ограничивает битрейт 6 мбит/с, так что у стримеров вопрос не в кодеке, а в железе.
Куда ещё жать-то?
>>3007889
Как книжки читаешь вместо кино, так и пользоваться.
>У ffmpeg за 20 лет гуя нет, как им пользоваться?
Как книжки читаешь вместо кино, так и пользоваться.
>>3007890
Книжки читать умеют все. Этому в школах учат.
А как работать с безгуйными приложениями не научат нигде, этому надо долгие месяцы обучаться, не отвлекаясь ни на что другое. Ну или вернуться на 20 лет назад и попросить родителей чтобы тебя отдали в школу где этому учат, а таких немного.
Книжки читать умеют все. Этому в школах учат.
А как работать с безгуйными приложениями не научат нигде, этому надо долгие месяцы обучаться, не отвлекаясь ни на что другое. Ну или вернуться на 20 лет назад и попросить родителей чтобы тебя отдали в школу где этому учат, а таких немного.
>>3007904
И там текст и там текст. Читаешь, понимаешь, пишешь. И понимать прочитанное, и следовать определённым правилам при написании в школе учат.
>А как работать с безгуйными приложениями не научат нигде, этому надо долгие месяцы обучаться, не отвлекаясь ни на что другое.
И там текст и там текст. Читаешь, понимаешь, пишешь. И понимать прочитанное, и следовать определённым правилам при написании в школе учат.
95 Кб, 1076x847В OBS, например, есть возможность отдать кодирование на аутсорс ffmpeg. А можно ли прикрутить ffmpeg к Vegas Pro? Хочется сжимать в vp9 veryslow напрямую из Vegas Pro без ещё одного перекодирования.
>>3007889
https://ffmpeg.org/ffmpeg-all.html
Вот тут все команды. Просто вводишь в консоль нужную. Если не нашёл/не понял - обращайся к поисковику, на сторонних сайтах бывают готовые решения под конкретные прикладные задачи.
>У ffmpeg за 20 лет гуя нет, как им пользоваться?
https://ffmpeg.org/ffmpeg-all.html
Вот тут все команды. Просто вводишь в консоль нужную. Если не нашёл/не понял - обращайся к поисковику, на сторонних сайтах бывают готовые решения под конкретные прикладные задачи.
>>3007404
HandBrake попроще, XMedia Recode пофункциональнее. В обоих можно дописать нужные текстовые команды, в отличие от FormatFactory.
HandBrake попроще, XMedia Recode пофункциональнее. В обоих можно дописать нужные текстовые команды, в отличие от FormatFactory.
>>3007889
прикинь! через консоль. прикинь, даже такому дауну, как я, это доступно.
прикинь! через консоль. прикинь, даже такому дауну, как я, это доступно.
>>3007888
Видео с камеры жму, с помощью CRF они весят намного меньше, а качество такое же
Видео с камеры жму, с помощью CRF они весят намного меньше, а качество такое же
>>3008053
facepalm.
WT это просто удобное окружение. cmd это cmd, powershell это powershell. Да и вообще его начали делать, я думаю, на волне WSL и WSL 2 чтобы ими было удобнее пользоваться.
>windows terminal
facepalm.
WT это просто удобное окружение. cmd это cmd, powershell это powershell. Да и вообще его начали делать, я думаю, на волне WSL и WSL 2 чтобы ими было удобнее пользоваться.
>>3008056
Под cmd ты подразумевал именно его стандартное окружение
Под cmd ты подразумевал именно его стандартное окружение
>>3007889
Да ладно, ничего сложного, это даже удобнее графических интерфейсов, хоть я и всегда за них топлю но для ffmpeg он реально не нужен.
> У ffmpeg за 20 лет гуя нет, как им пользоваться?
Да ладно, ничего сложного, это даже удобнее графических интерфейсов, хоть я и всегда за них топлю но для ffmpeg он реально не нужен.
>>3007929
>>3007992
Потому что это поколение и правда ничему такому не учили, тяжело им будет на готовых скриптах жить в эпоху говнософта.
>>3007904
Проблема-то ещё в том что всё это коммьюнити секта свидетелей опенсорса и "безгуйных" приложений - самое токсичное во всём Интернете. Если чего-то не нагуглишь или не поймёшь - хуй тебе кто поможет, ещё и неосилятором назовут, а то и пидором (а это хуже всего, потом кличка такая будет).
>>3007992
Потому что это поколение и правда ничему такому не учили, тяжело им будет на готовых скриптах жить в эпоху говнософта.
>>3007904
Проблема-то ещё в том что всё это коммьюнити секта свидетелей опенсорса и "безгуйных" приложений - самое токсичное во всём Интернете. Если чего-то не нагуглишь или не поймёшь - хуй тебе кто поможет, ещё и неосилятором назовут, а то и пидором (а это хуже всего, потом кличка такая будет).
>>3007888
У libvpx-vp9 нет пресетов как у x264. Там вместо этого speed/cpu-used и deadline/quality. Или ты пользуешся каким-то другим кодировщиком vp9?
> vp9 veryslow
У libvpx-vp9 нет пресетов как у x264. Там вместо этого speed/cpu-used и deadline/quality. Или ты пользуешся каким-то другим кодировщиком vp9?
>>3008097
Чему там учить? Открыть cmd и вписать команду? жмешь win+r и пишешь cmd. Все. Ты гуру.
Сравни здешние треды винды и линукса по "токсичности". На гитхабе в issues так вообще лепота и милота.
Но никто талдычить и разжевывать одно и то же человеку не способному в мануалы ленивому пользователю с желанием сделайте мне хорошо не будет. Народ же не индусы поддержки майкрософта/яблока, а программисты/продвинутые пользователи с альтруистическими настроениями. Прост лентяя, не могущего инструкцию вводную прочитать никто не держит, ибо он не нужен, только время крадет. С вменяемыми людьми всегда просто и легко все получается.
>Потому что это поколение и правда ничему такому не учили
Чему там учить? Открыть cmd и вписать команду? жмешь win+r и пишешь cmd. Все. Ты гуру.
>секта свидетелей опенсорса и "безгуйных" приложений - самое токсичное во всём Интернете
Сравни здешние треды винды и линукса по "токсичности". На гитхабе в issues так вообще лепота и милота.
Но никто талдычить и разжевывать одно и то же человеку не способному в мануалы ленивому пользователю с желанием сделайте мне хорошо не будет. Народ же не индусы поддержки майкрософта/яблока, а программисты/продвинутые пользователи с альтруистическими настроениями. Прост лентяя, не могущего инструкцию вводную прочитать никто не держит, ибо он не нужен, только время крадет. С вменяемыми людьми всегда просто и легко все получается.
>>3007606
дрочую
носятся с этим ав1 как дауны
даже топ железе придется ждать сутки чтобы перекодировать что то
дрочую
носятся с этим ав1 как дауны
даже топ железе придется ждать сутки чтобы перекодировать что то
>>3008097
>>3007904
меня тоже никто ничему такому не учил. просто не для всего софта выполняющего задачи эффективно, есть гуй. и с этим рано или поздно сталкиваешься.
ключевое тут "эффективно".
можно для элементарнейших, по сути, задач типа обрезки или кропа видео загружать пиздецки прожорливый комбайн от Adobe.
при использовании ffmpeg со временем набивается рука и в черновик записываются типовые сниппеты нужные только тебе и это сильно упрощает всё.
пока найдешь в том гуе где какую галочку нажать и куда значение вводить с ума сойдешь. а если оно еще и не вводится по какой то причине или все работает "не так как должно" по тому что где то что то не так нажал и/или не в том порядке. оой бля. можно бесконечно продолжать.
нет, надо просто столкнуться с проблемой. премьер про тоже долго надо обучаться. да и в общем, всему надо долго обучаться.
>>3008106
двачую адеквата
>>3007904
меня тоже никто ничему такому не учил. просто не для всего софта выполняющего задачи эффективно, есть гуй. и с этим рано или поздно сталкиваешься.
ключевое тут "эффективно".
можно для элементарнейших, по сути, задач типа обрезки или кропа видео загружать пиздецки прожорливый комбайн от Adobe.
при использовании ffmpeg со временем набивается рука и в черновик записываются типовые сниппеты нужные только тебе и это сильно упрощает всё.
пока найдешь в том гуе где какую галочку нажать и куда значение вводить с ума сойдешь. а если оно еще и не вводится по какой то причине или все работает "не так как должно" по тому что где то что то не так нажал и/или не в том порядке. оой бля. можно бесконечно продолжать.
> этому надо долгие месяцы обучаться
нет, надо просто столкнуться с проблемой. премьер про тоже долго надо обучаться. да и в общем, всему надо долго обучаться.
>>3008106
>Прост лентяя, не могущего инструкцию
двачую адеквата
>>3008132
Срачельничек, так сказать, готов принимать новые величины!
> при использовании ffmpeg со временем набивается рука
Срачельничек, так сказать, готов принимать новые величины!
>>3008132
Двачую, набил руку в онемешных вебм тредах, по работе несколько раз пригождалось быстро сделать всякую хуйню типа обрезки, наложения сабов, конвертирования в заданные размеры с макс качеством. С гуевым софтом ебался бы значительно дольше
Двачую, набил руку в онемешных вебм тредах, по работе несколько раз пригождалось быстро сделать всякую хуйню типа обрезки, наложения сабов, конвертирования в заданные размеры с макс качеством. С гуевым софтом ебался бы значительно дольше
>>3008106
С зажатой клавишей шифт кликаешь правой кнопкой мыши по папке где лежит софтина и кликаешь на пункт "открыть командную строку здесь."
Или же открываешь саму папку, в адресной строке пишешь cmd и enter.
В Classic Shell вообще божественная фича есть, кнопки "открыть командную строку" и "открыть командную строку от админа".
Когда совсем юзверем был долго думал над тем как путь к эксешнику нужному указать, там же по дефолту System32 открывается.
Я не знаю, может только мне такие мудаки попадались, но с проблемой выше мне только один человек из целого чата помог разобраться. Хотя может и правда чат такой был.
>жмешь win+r и пишешь cmd
С зажатой клавишей шифт кликаешь правой кнопкой мыши по папке где лежит софтина и кликаешь на пункт "открыть командную строку здесь."
Или же открываешь саму папку, в адресной строке пишешь cmd и enter.
В Classic Shell вообще божественная фича есть, кнопки "открыть командную строку" и "открыть командную строку от админа".
Когда совсем юзверем был долго думал над тем как путь к эксешнику нужному указать, там же по дефолту System32 открывается.
Я не знаю, может только мне такие мудаки попадались, но с проблемой выше мне только один человек из целого чата помог разобраться. Хотя может и правда чат такой был.
215 Кб, 2407x825>>3008163
А еще лучше используешь пикрил. Я от себя рекомендую PRE версию. Пока до релиза штуки дойдут (если дойдут), поседеешь. Ну как обычно.
https://github.com/microsoft/terminal
А еще лучше используешь пикрил. Я от себя рекомендую PRE версию. Пока до релиза штуки дойдут (если дойдут), поседеешь. Ну как обычно.
https://github.com/microsoft/terminal
>>3008322
Нихуя подобного, можно пользоваться только 4-6, щя скину
Нихуя подобного, можно пользоваться только 4-6, щя скину
Вечер в хату, первый раз занялся энтим вашенским кодированием.
Пытаюсь заставить современную аниму (mkv hevc + flac+встроенные субтитры .ass) работать на встроенном плеере старого самсунг смарт тв.
Подобрал подходящие видео и аудио кодеки (-c:v libx264 -c:a aac) но вот с субтитрами какая-то хуйня.
Ели их вырезать (-sn) то все работает, а вот если оставить то телевизор просто вырубается к ебени матери при попытке проиграть файл (на компе все работает)
И хотя в документации и написано что встроенные в .mkv .ass должны поддерживаться, но судя по результату - нихуя.
Может это я туплю и при изменении видео\аудиокодека нужно каким-то образом переформатировать и субтитры?
Что можно с ними сделать чтобы они таки заработали?
Пытаюсь заставить современную аниму (mkv hevc + flac+встроенные субтитры .ass) работать на встроенном плеере старого самсунг смарт тв.
Подобрал подходящие видео и аудио кодеки (-c:v libx264 -c:a aac) но вот с субтитрами какая-то хуйня.
Ели их вырезать (-sn) то все работает, а вот если оставить то телевизор просто вырубается к ебени матери при попытке проиграть файл (на компе все работает)
И хотя в документации и написано что встроенные в .mkv .ass должны поддерживаться, но судя по результату - нихуя.
Может это я туплю и при изменении видео\аудиокодека нужно каким-то образом переформатировать и субтитры?
Что можно с ними сделать чтобы они таки заработали?
>>3008396
Благодарю, попробуемс.
Благодарю, попробуемс.
>>3008368
ТВ только bitmap субтитры поддерживают.
ТВ только bitmap субтитры поддерживают.
>>3008368
Сука, просто купи андроид приставку и не ебись с этой хуйней, она стоит копейки
Сука, просто купи андроид приставку и не ебись с этой хуйней, она стоит копейки
>>3008309
>>3008322
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 6 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 19 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 1 -an -f null -
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 6 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 19 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 2 -c:a libopus -b:a 160k -filter:a "aresample=48000:resampler=soxr:precision=33" "out.webm"
https://www.reddit.com/r/AV1/comments/lfheh9/encoder_tuning_part_2_making_aomencav1libaomav1/
>>3008322
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 6 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 19 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 1 -an -f null -
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 6 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 19 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 2 -c:a libopus -b:a 160k -filter:a "aresample=48000:resampler=soxr:precision=33" "out.webm"
https://www.reddit.com/r/AV1/comments/lfheh9/encoder_tuning_part_2_making_aomencav1libaomav1/
>>3008898
В av1 он по умолчанию
В av1 он по умолчанию
>>3008396
>>3008452
-vf выдавал ошибки поэтому в результате сделал через -filter_complex "subtitles=видос.mkv"
Все работает.
>>3008480
Да я сначала тоже думал что ебал я в рот каждый раз этим заниматься, да еще и для каждого файла.
Но после десяти минут гугла наткнулся вот на этот гуй sourceforge.net/projects/ffmpeg-batch/ в котором без особых проблем запилил себе универсальный пресет, способный любую современную аниму (в любом количестве) переварить в подходящий для моего тв вариант за два клика.
Мне нраица.
>>3008452
-vf выдавал ошибки поэтому в результате сделал через -filter_complex "subtitles=видос.mkv"
Все работает.
>>3008480
Да я сначала тоже думал что ебал я в рот каждый раз этим заниматься, да еще и для каждого файла.
Но после десяти минут гугла наткнулся вот на этот гуй sourceforge.net/projects/ffmpeg-batch/ в котором без особых проблем запилил себе универсальный пресет, способный любую современную аниму (в любом количестве) переварить в подходящий для моего тв вариант за два клика.
Мне нраица.
>>3008172
Хуйня. Поиска по тексту нет, многооконности нет. ConEmu лучше будет. А Windows Terminal ещё и анально привязан к M$ Store, бгг.
Хуйня. Поиска по тексту нет, многооконности нет. ConEmu лучше будет. А Windows Terminal ещё и анально привязан к M$ Store, бгг.
Охуеть, оказывается ффмпег может взять и неплохо стабилизировать трясущийся видос, гамму может подкрутить, обрезать кусок кадра. А может ли он превратить дёрганые 30фпс в плавненькие 60? Древние 176х144 апскейльнуть в фуллхд лол? Или это нейросеть нужна, чтобы недостающие кадры и детали дорисовывать? А эффект типа HDR у него есть, чтобы не было пересветов и затемнённых участков? А подавление шума без "целлофана"?
>>3009057
Два прохода, сначала создастся промежуточный файл transforms.trf, потом непосредственно штабилизация:
ffmpeg -i video.mp4 -vf vidstabdetect -f null -
ffmpeg -i video.mp4 -vf vidstabtransform=smoothing=5:input="transforms.trf" -c:v libvpx-vp9 -b:v xxxK -crf 4 -c:a libopus -b:a xxK video_stab.webm
понятно, если в шебм пожать хочешь
> Как?
Два прохода, сначала создастся промежуточный файл transforms.trf, потом непосредственно штабилизация:
ffmpeg -i video.mp4 -vf vidstabdetect -f null -
ffmpeg -i video.mp4 -vf vidstabtransform=smoothing=5:input="transforms.trf" -c:v libvpx-vp9 -b:v xxxK -crf 4 -c:a libopus -b:a xxK video_stab.webm
понятно, если в шебм пожать хочешь
275 Кб, 780x593>>3009055
> Охуеть, оказывается ффмпег может взять и неплохо стабилизировать трясущийся видос, гамму может подкрутить, обрезать кусок кадра. А может ли он превратить дёрганые 30фпс в плавненькие 60? Древние 176х144 апскейльнуть в фуллхд лол? Или это нейросеть нужна, чтобы недостающие кадры и детали дорисовывать? А эффект типа HDR у него есть, чтобы не было пересветов и затемнённых участков? А подавление шума без "целлофана"?
>>3009057
Какое "ещё"? Я только один пост в вашем обсуждении написал.
Конечно не пользуюсь. После удаления службы центра обновлений эта хуйня не работает. В принципе он бесполезен, так что похуй.
Говноеды - это любители магазинов приложений. В магазине нет portable версий, чтобы иметь на устройстве несколько копий программы с независимыми настройками. При переустановки системы абсолютно не ясно, каким образом будут синхронизироваться данные. Ведь в случае с обычными бинарями я могу переписать файлы, а там наверняка какие-то облачные службы, которые могут не сработать, могут сработать криво, или могут не сработать потому-что моё поведение не понравилось барину и он счёл меня пердолей. И всё это говно привязано к кучи компонентов, которые так и норовят сломаться, и если это произойдёт, то ты потеряешь доступ к установке, переустановке и обновлениям приложений.
Не говоря уже о том, что там практически нет нормального ПО. Какая-то адварь, какие-то детские игрушки, браузеры мошенников, payware-мусор не умеющий ничего, uwp от Micro$oft, унылый кал от васяна - больше там ничего нет. Из +/- достойного софта могу выделить только EarTrumped и Windows Terminal. Первый является альтернативой дефолтному микшеру громкости, и я не вижу в нём ничего хорошего кроме дизайна, и сильно сомневаюсь в том, что он умеет в управление с клавиатуры и быстрый mute по нажатию клавиши. Второй лучше дефолтного cmd - красивее, можно gif-ки на задний фон ставить, вкладки есть, но сильно уступает ConEmu - нет поиска по тексту и нет размещения нескольких консолей внутри одного окна.
>А, ты ещё
Какое "ещё"? Я только один пост в вашем обсуждении написал.
>ты ещё и этим божественным магазином не пользуешься
Конечно не пользуюсь. После удаления службы центра обновлений эта хуйня не работает. В принципе он бесполезен, так что похуй.
>10 говноедов из 10
Говноеды - это любители магазинов приложений. В магазине нет portable версий, чтобы иметь на устройстве несколько копий программы с независимыми настройками. При переустановки системы абсолютно не ясно, каким образом будут синхронизироваться данные. Ведь в случае с обычными бинарями я могу переписать файлы, а там наверняка какие-то облачные службы, которые могут не сработать, могут сработать криво, или могут не сработать потому-что моё поведение не понравилось барину и он счёл меня пердолей. И всё это говно привязано к кучи компонентов, которые так и норовят сломаться, и если это произойдёт, то ты потеряешь доступ к установке, переустановке и обновлениям приложений.
Не говоря уже о том, что там практически нет нормального ПО. Какая-то адварь, какие-то детские игрушки, браузеры мошенников, payware-мусор не умеющий ничего, uwp от Micro$oft, унылый кал от васяна - больше там ничего нет. Из +/- достойного софта могу выделить только EarTrumped и Windows Terminal. Первый является альтернативой дефолтному микшеру громкости, и я не вижу в нём ничего хорошего кроме дизайна, и сильно сомневаюсь в том, что он умеет в управление с клавиатуры и быстрый mute по нажатию клавиши. Второй лучше дефолтного cmd - красивее, можно gif-ки на задний фон ставить, вкладки есть, но сильно уступает ConEmu - нет поиска по тексту и нет размещения нескольких консолей внутри одного окна.
>>3009291
Чтобы компьютер служил мне, а не я служил компьютеру, постоянно переучиваясь к новым фичам/редизайну и постоянно решая проблемы вызванные обновами. Алсо, по несколько раз в месяц, вместо начала/завершения работы, ждать пока Windows завершит обновление - терпилизм-куколдизм, у меня есть более лучшие способы потратить время.
Чтобы компьютер служил мне, а не я служил компьютеру, постоянно переучиваясь к новым фичам/редизайну и постоянно решая проблемы вызванные обновами. Алсо, по несколько раз в месяц, вместо начала/завершения работы, ждать пока Windows завершит обновление - терпилизм-куколдизм, у меня есть более лучшие способы потратить время.
>>3009306
Что и требовалось доказать, образцовый говноед.
Что и требовалось доказать, образцовый говноед.
31 Кб, 1337x757>>3009049
Ты про split panes? Так они есть, привет. https://docs.microsoft.com/en-us/windows/terminal/panes
И он тоже есть, деточка https://docs.microsoft.com/en-us/windows/terminal/search
И с вкладками тоже все впорядке. Они в том же окне открываются.
Хотя блять я же говорю с шизоидом который нахуято удалил службы центра обновлений (если я правильно понимаю о чем они).
Спойлер: а с появлением WSL все эти ConEmu и MinGW стали нахуй не нужны.
>многооконности нет
Ты про split panes? Так они есть, привет. https://docs.microsoft.com/en-us/windows/terminal/panes
> Поиска по тексту нет
И он тоже есть, деточка https://docs.microsoft.com/en-us/windows/terminal/search
И с вкладками тоже все впорядке. Они в том же окне открываются.
Хотя блять я же говорю с шизоидом который нахуято удалил службы центра обновлений (если я правильно понимаю о чем они).
Спойлер: а с появлением WSL все эти ConEmu и MinGW стали нахуй не нужны.
>>3009289
Иди лечись.
Иди лечись.
>>3009314
Ну окей, показывай мне способ запустить его по-нормальному, без привязки к MicroShit $tore.
Ну окей, показывай мне способ запустить его по-нормальному, без привязки к MicroShit $tore.
у кого-нибудь есть vvenc скомпиленная?
>>3009537
значит тебе не нужен. я же сказал что с его выходом всякие mingw нахуй стали не нужны. а вообще с выходом WSL2 для большинства задач теперь нет необходимости ставить виртуальную машину. там щас и аппаратное ускорение и возможность запустить гуй приложение линуксовое и все такое.
>>3009533
ну если ты такой еблан что тебе проще собирать руками из исходников чем установить из маркета то на гитхабе есть инструкция по сборке:
https://github.com/microsoft/terminal
и сходи к доктору. обязательно
значит тебе не нужен. я же сказал что с его выходом всякие mingw нахуй стали не нужны. а вообще с выходом WSL2 для большинства задач теперь нет необходимости ставить виртуальную машину. там щас и аппаратное ускорение и возможность запустить гуй приложение линуксовое и все такое.
>>3009533
ну если ты такой еблан что тебе проще собирать руками из исходников чем установить из маркета то на гитхабе есть инструкция по сборке:
https://github.com/microsoft/terminal
и сходи к доктору. обязательно
>>3009722
А для говноедов, коим является Firefox, поддерживает?
А для говноедов, коим является Firefox, поддерживает?
296 Кб, 3027x1421>>3009666
Странная хуйня происходит.
На виртуальной машине, по гайду с ютуба у меня получилось включить обновления и установить Windows Terminal (оказывается нужно было восстановить повреждённый реестр). Потом я пытался повторить успех на основной системе, но нихуя не вышло. Вернее служба обновлений заработала, метро настройки начали что-то качать, но Windows Terminal не хотел устанавливаться. Раньше при установке из того хитровыебанного файла он распаковывал свои файлы, у него изменялся прогресс-бар, а по окончанию приложение не запускалось. Сейчас же установщик вылетает в самом начале установке, после нажатия главной кнопки. Я решил скопировать каталоги, в которых Windows Terminal лежит на виртуальной машине, в основную систему. Я знал, что у меня это не получится. Но, как не странно, получилось.
Странная хуйня происходит.
На виртуальной машине, по гайду с ютуба у меня получилось включить обновления и установить Windows Terminal (оказывается нужно было восстановить повреждённый реестр). Потом я пытался повторить успех на основной системе, но нихуя не вышло. Вернее служба обновлений заработала, метро настройки начали что-то качать, но Windows Terminal не хотел устанавливаться. Раньше при установке из того хитровыебанного файла он распаковывал свои файлы, у него изменялся прогресс-бар, а по окончанию приложение не запускалось. Сейчас же установщик вылетает в самом начале установке, после нажатия главной кнопки. Я решил скопировать каталоги, в которых Windows Terminal лежит на виртуальной машине, в основную систему. Я знал, что у меня это не получится. Но, как не странно, получилось.
>>3009785
Осталось только попытаться установить NET Framework 3.5.
Осталось только попытаться установить NET Framework 3.5.
>>3009835
Это ко всем хромогам относится, вне зависимости от наличия анального зонда гугла.
>У него шизофрения диагностирована
Это ко всем хромогам относится, вне зависимости от наличия анального зонда гугла.
>>3009838
Тот именно что самый настоящий шизофреник. Стоило мне немножко ткнуть палочкой в его шизомирок с пруфами, так он меня теперь по всему /s/ ищет, кидаясь на левых анонов.
Тот именно что самый настоящий шизофреник. Стоило мне немножко ткнуть палочкой в его шизомирок с пруфами, так он меня теперь по всему /s/ ищет, кидаясь на левых анонов.
>>3009681
Докажи.
Докажи.
42 Кб, 1153x434>>3009785
они готовые msixbundle пакеты в ассетах выкладывают оказывается
For users who are unable to install Windows Terminal from the Microsoft Store
https://github.com/microsoft/terminal/releases/tag/v1.9.1445.0
https://github.com/microsoft/terminal/releases/download/v1.9.1445.0/Microsoft.WindowsTerminalPreview_1.9.1445.0_8wekyb3d8bbwe.msixbundle
но тогда обновления сами прилетать не будут
они готовые msixbundle пакеты в ассетах выкладывают оказывается
For users who are unable to install Windows Terminal from the Microsoft Store
https://github.com/microsoft/terminal/releases/tag/v1.9.1445.0
https://github.com/microsoft/terminal/releases/download/v1.9.1445.0/Microsoft.WindowsTerminalPreview_1.9.1445.0_8wekyb3d8bbwe.msixbundle
но тогда обновления сами прилетать не будут
Черт, только что запостил свой вопрос в тред про видеоплееры, так как не нашел более подходящего, а теперь нашел подходящий. Ну, продублирую.
TL;DR: есть несколько видеофайлов, контейнер MP4, внутри видеопоток x264, настройки кодирования одинаковые. При склейке без перекодирования разные тулзы (Avidemux и MP4Joiner) выдают склеенное видео, в котором некоторые из кусков (разные, в зависимости от тулзы) повреждены. Первый ключевой кадр серый или фиолетовый, последующие ожидаемо идут по пизде. Отчего такое происходит? Какая-то проблема в исходных склеиваемых?
Полный текст, скопировано из соседнего треда:
Есть несколько файлов MP4, внутри которых видеопоток в x264. Все файлы с одинаковым фпс, одинаковым размером кадра, и закодированы с одними и теми же настройками (отвечаю, лично делал). Знаю, что в таком случае можно склеить их в один видеофайл без перекодирования.
Но это ожидание. А реальность:
Avidemux (в режиме copy для видеопотока) выдает файл, в котором некоторые из этих кусков (именно некоторые) заполнены мусором вместо реального содержимого кадров. Такое впечатление, что первый ключевой кадр в начале такого куска просто залит серым, и все остальные кадры за ним идут по пизде. Потом картинка снова становится нормальной в момент переключения на следующий кусок, который обработан нормально.
MP4Joiner из MP4Tools (который является просто гуишной оберткой над какой-то cli-утилитой для работы с mp4) часто делает то же самое, но при этом "поврежденными" оказываются некоторые другие куски из того же набора. Какой-либо зависимости, какие именно куски повреждаются, я не увидел.
Если склеенный видеофайл был создан MP4Joiner'ом и там каким-то чудом все куски не повреждены, то в видеоплеере (любом, по дефолту юзаю MPC-HC) он воспроизводится нормально, а вот при открытии Avidemux'ом вижу ту же хуету с серыми кадрами.
Если закинуть все куски в Avidemux и склеить их С перекодированием (режим не copy, а выбор одного из кодировщиков), то получается нормальное видео, но в моменты переключения с одного куска на другой видео при воспоизведении как будто подвисает на пару кадров (в том же MPC-HC). "Зависание" заметно невооруженным глазом. Шагал по нему покадрово - там нету дублирующих кадров. Может быть такое, что у какого-то кадра (например, первого или последнего в куске) длина отлична от указанного фпс?
Вот залил для примера четыре куска: MP4Joiner справляется, Avidemux делает поврежденные куски в итоговом видео (кадр залит хуетой). Если их совместить в MP4Joiner и открыть в Avidemux, видео там начнется с поврежденного куска, залитого серым, хотя видеоплеер справляется.
Куски 1, 2 и 4 - пикрелейтед, 3-й не влез в пост (лимит 40 МБ), так что вот 3-й отдельно: https://www106.zippyshare.com/v/PRc4ujMt/file.html
(да, это тот самый жанр видео ¯\_(ツ)_/¯)
Предупреждая вопрос: нахуя я вообще с этим ебусь, почему не делать в видеоредакторе - потому что хочу взять поток кадров из видео и просто создать видео с 15 фпс, т.е. замедлить и заодно сделать сам "проект" в 15 фпс. В простых редакторах типа Avidemux и VirtualDub это делается легко, в тяжеловесных - более муторно, к тому же фпс у исходных видеофайлов с телефона почему-то равен примерно 29.xxx и является variable, колеблется от 29.xxx до 30.xxx. Я хз, что это за хуета, и не является ли она источником проблемы.
TL;DR: есть несколько видеофайлов, контейнер MP4, внутри видеопоток x264, настройки кодирования одинаковые. При склейке без перекодирования разные тулзы (Avidemux и MP4Joiner) выдают склеенное видео, в котором некоторые из кусков (разные, в зависимости от тулзы) повреждены. Первый ключевой кадр серый или фиолетовый, последующие ожидаемо идут по пизде. Отчего такое происходит? Какая-то проблема в исходных склеиваемых?
Полный текст, скопировано из соседнего треда:
Есть несколько файлов MP4, внутри которых видеопоток в x264. Все файлы с одинаковым фпс, одинаковым размером кадра, и закодированы с одними и теми же настройками (отвечаю, лично делал). Знаю, что в таком случае можно склеить их в один видеофайл без перекодирования.
Но это ожидание. А реальность:
Avidemux (в режиме copy для видеопотока) выдает файл, в котором некоторые из этих кусков (именно некоторые) заполнены мусором вместо реального содержимого кадров. Такое впечатление, что первый ключевой кадр в начале такого куска просто залит серым, и все остальные кадры за ним идут по пизде. Потом картинка снова становится нормальной в момент переключения на следующий кусок, который обработан нормально.
MP4Joiner из MP4Tools (который является просто гуишной оберткой над какой-то cli-утилитой для работы с mp4) часто делает то же самое, но при этом "поврежденными" оказываются некоторые другие куски из того же набора. Какой-либо зависимости, какие именно куски повреждаются, я не увидел.
Если склеенный видеофайл был создан MP4Joiner'ом и там каким-то чудом все куски не повреждены, то в видеоплеере (любом, по дефолту юзаю MPC-HC) он воспроизводится нормально, а вот при открытии Avidemux'ом вижу ту же хуету с серыми кадрами.
Если закинуть все куски в Avidemux и склеить их С перекодированием (режим не copy, а выбор одного из кодировщиков), то получается нормальное видео, но в моменты переключения с одного куска на другой видео при воспоизведении как будто подвисает на пару кадров (в том же MPC-HC). "Зависание" заметно невооруженным глазом. Шагал по нему покадрово - там нету дублирующих кадров. Может быть такое, что у какого-то кадра (например, первого или последнего в куске) длина отлична от указанного фпс?
Вот залил для примера четыре куска: MP4Joiner справляется, Avidemux делает поврежденные куски в итоговом видео (кадр залит хуетой). Если их совместить в MP4Joiner и открыть в Avidemux, видео там начнется с поврежденного куска, залитого серым, хотя видеоплеер справляется.
Куски 1, 2 и 4 - пикрелейтед, 3-й не влез в пост (лимит 40 МБ), так что вот 3-й отдельно: https://www106.zippyshare.com/v/PRc4ujMt/file.html
(да, это тот самый жанр видео ¯\_(ツ)_/¯)
Предупреждая вопрос: нахуя я вообще с этим ебусь, почему не делать в видеоредакторе - потому что хочу взять поток кадров из видео и просто создать видео с 15 фпс, т.е. замедлить и заодно сделать сам "проект" в 15 фпс. В простых редакторах типа Avidemux и VirtualDub это делается легко, в тяжеловесных - более муторно, к тому же фпс у исходных видеофайлов с телефона почему-то равен примерно 29.xxx и является variable, колеблется от 29.xxx до 30.xxx. Я хз, что это за хуета, и не является ли она источником проблемы.
Черт, только что запостил свой вопрос в тред про видеоплееры, так как не нашел более подходящего, а теперь нашел подходящий. Ну, продублирую.
TL;DR: есть несколько видеофайлов, контейнер MP4, внутри видеопоток x264, настройки кодирования одинаковые. При склейке без перекодирования разные тулзы (Avidemux и MP4Joiner) выдают склеенное видео, в котором некоторые из кусков (разные, в зависимости от тулзы) повреждены. Первый ключевой кадр серый или фиолетовый, последующие ожидаемо идут по пизде. Отчего такое происходит? Какая-то проблема в исходных склеиваемых?
Полный текст, скопировано из соседнего треда:
Есть несколько файлов MP4, внутри которых видеопоток в x264. Все файлы с одинаковым фпс, одинаковым размером кадра, и закодированы с одними и теми же настройками (отвечаю, лично делал). Знаю, что в таком случае можно склеить их в один видеофайл без перекодирования.
Но это ожидание. А реальность:
Avidemux (в режиме copy для видеопотока) выдает файл, в котором некоторые из этих кусков (именно некоторые) заполнены мусором вместо реального содержимого кадров. Такое впечатление, что первый ключевой кадр в начале такого куска просто залит серым, и все остальные кадры за ним идут по пизде. Потом картинка снова становится нормальной в момент переключения на следующий кусок, который обработан нормально.
MP4Joiner из MP4Tools (который является просто гуишной оберткой над какой-то cli-утилитой для работы с mp4) часто делает то же самое, но при этом "поврежденными" оказываются некоторые другие куски из того же набора. Какой-либо зависимости, какие именно куски повреждаются, я не увидел.
Если склеенный видеофайл был создан MP4Joiner'ом и там каким-то чудом все куски не повреждены, то в видеоплеере (любом, по дефолту юзаю MPC-HC) он воспроизводится нормально, а вот при открытии Avidemux'ом вижу ту же хуету с серыми кадрами.
Если закинуть все куски в Avidemux и склеить их С перекодированием (режим не copy, а выбор одного из кодировщиков), то получается нормальное видео, но в моменты переключения с одного куска на другой видео при воспоизведении как будто подвисает на пару кадров (в том же MPC-HC). "Зависание" заметно невооруженным глазом. Шагал по нему покадрово - там нету дублирующих кадров. Может быть такое, что у какого-то кадра (например, первого или последнего в куске) длина отлична от указанного фпс?
Вот залил для примера четыре куска: MP4Joiner справляется, Avidemux делает поврежденные куски в итоговом видео (кадр залит хуетой). Если их совместить в MP4Joiner и открыть в Avidemux, видео там начнется с поврежденного куска, залитого серым, хотя видеоплеер справляется.
Куски 1, 2 и 4 - пикрелейтед, 3-й не влез в пост (лимит 40 МБ), так что вот 3-й отдельно: https://www106.zippyshare.com/v/PRc4ujMt/file.html
(да, это тот самый жанр видео ¯\_(ツ)_/¯)
Предупреждая вопрос: нахуя я вообще с этим ебусь, почему не делать в видеоредакторе - потому что хочу взять поток кадров из видео и просто создать видео с 15 фпс, т.е. замедлить и заодно сделать сам "проект" в 15 фпс. В простых редакторах типа Avidemux и VirtualDub это делается легко, в тяжеловесных - более муторно, к тому же фпс у исходных видеофайлов с телефона почему-то равен примерно 29.xxx и является variable, колеблется от 29.xxx до 30.xxx. Я хз, что это за хуета, и не является ли она источником проблемы.
TL;DR: есть несколько видеофайлов, контейнер MP4, внутри видеопоток x264, настройки кодирования одинаковые. При склейке без перекодирования разные тулзы (Avidemux и MP4Joiner) выдают склеенное видео, в котором некоторые из кусков (разные, в зависимости от тулзы) повреждены. Первый ключевой кадр серый или фиолетовый, последующие ожидаемо идут по пизде. Отчего такое происходит? Какая-то проблема в исходных склеиваемых?
Полный текст, скопировано из соседнего треда:
Есть несколько файлов MP4, внутри которых видеопоток в x264. Все файлы с одинаковым фпс, одинаковым размером кадра, и закодированы с одними и теми же настройками (отвечаю, лично делал). Знаю, что в таком случае можно склеить их в один видеофайл без перекодирования.
Но это ожидание. А реальность:
Avidemux (в режиме copy для видеопотока) выдает файл, в котором некоторые из этих кусков (именно некоторые) заполнены мусором вместо реального содержимого кадров. Такое впечатление, что первый ключевой кадр в начале такого куска просто залит серым, и все остальные кадры за ним идут по пизде. Потом картинка снова становится нормальной в момент переключения на следующий кусок, который обработан нормально.
MP4Joiner из MP4Tools (который является просто гуишной оберткой над какой-то cli-утилитой для работы с mp4) часто делает то же самое, но при этом "поврежденными" оказываются некоторые другие куски из того же набора. Какой-либо зависимости, какие именно куски повреждаются, я не увидел.
Если склеенный видеофайл был создан MP4Joiner'ом и там каким-то чудом все куски не повреждены, то в видеоплеере (любом, по дефолту юзаю MPC-HC) он воспроизводится нормально, а вот при открытии Avidemux'ом вижу ту же хуету с серыми кадрами.
Если закинуть все куски в Avidemux и склеить их С перекодированием (режим не copy, а выбор одного из кодировщиков), то получается нормальное видео, но в моменты переключения с одного куска на другой видео при воспоизведении как будто подвисает на пару кадров (в том же MPC-HC). "Зависание" заметно невооруженным глазом. Шагал по нему покадрово - там нету дублирующих кадров. Может быть такое, что у какого-то кадра (например, первого или последнего в куске) длина отлична от указанного фпс?
Вот залил для примера четыре куска: MP4Joiner справляется, Avidemux делает поврежденные куски в итоговом видео (кадр залит хуетой). Если их совместить в MP4Joiner и открыть в Avidemux, видео там начнется с поврежденного куска, залитого серым, хотя видеоплеер справляется.
Куски 1, 2 и 4 - пикрелейтед, 3-й не влез в пост (лимит 40 МБ), так что вот 3-й отдельно: https://www106.zippyshare.com/v/PRc4ujMt/file.html
(да, это тот самый жанр видео ¯\_(ツ)_/¯)
Предупреждая вопрос: нахуя я вообще с этим ебусь, почему не делать в видеоредакторе - потому что хочу взять поток кадров из видео и просто создать видео с 15 фпс, т.е. замедлить и заодно сделать сам "проект" в 15 фпс. В простых редакторах типа Avidemux и VirtualDub это делается легко, в тяжеловесных - более муторно, к тому же фпс у исходных видеофайлов с телефона почему-то равен примерно 29.xxx и является variable, колеблется от 29.xxx до 30.xxx. Я хз, что это за хуета, и не является ли она источником проблемы.
>>3010546
Апдейт:
В соседнем треде посоветовали склеить ffmpeg'ом. Сделал по инструкции отсюда: http://trac.ffmpeg.org/wiki/Concatenate#demuxer
ffmpeg -f concat -safe 0 -i D:\folder\list.txt -c copy result.mp4
Вроде бы все прошло успешно, ffmpeg осилил эти исходные куски, проблем с воспроизведением и артефактами в получившемся файле вроде бы не наблюдаю.
Однако почему-то у склеенного ffmpeg'ом файла характеристики fps такие:
Frame rate mode : Variable
Frame rate : 15.000 FPS
Minimum frame rate : 14.851 FPS
Maximum frame rate : 15.000 FPS
В то время как у всех четырех исходных, из которых склеивал, они такие:
Frame rate mode : Constant
Frame rate : 15.000 FPS
Исходные четыре файла - см. предыдущий пост >>3010546 . Склеенный ffmpeg'ом файл: https://www25.zippyshare.com/v/kihcYvT3/file.html . Как так получилось, чем это грозит и как (и надо ли) исправлять?
Апдейт:
В соседнем треде посоветовали склеить ffmpeg'ом. Сделал по инструкции отсюда: http://trac.ffmpeg.org/wiki/Concatenate#demuxer
ffmpeg -f concat -safe 0 -i D:\folder\list.txt -c copy result.mp4
Вроде бы все прошло успешно, ffmpeg осилил эти исходные куски, проблем с воспроизведением и артефактами в получившемся файле вроде бы не наблюдаю.
Однако почему-то у склеенного ffmpeg'ом файла характеристики fps такие:
Frame rate mode : Variable
Frame rate : 15.000 FPS
Minimum frame rate : 14.851 FPS
Maximum frame rate : 15.000 FPS
В то время как у всех четырех исходных, из которых склеивал, они такие:
Frame rate mode : Constant
Frame rate : 15.000 FPS
Исходные четыре файла - см. предыдущий пост >>3010546 . Склеенный ffmpeg'ом файл: https://www25.zippyshare.com/v/kihcYvT3/file.html . Как так получилось, чем это грозит и как (и надо ли) исправлять?
>>3010707
В смысле, передать точно такие же параметры ffmpeg'у, но расширение указать как .mkv, а не .mp4, и он автоматом поймет, что я хочу контейнер mkv?
В смысле, передать точно такие же параметры ffmpeg'у, но расширение указать как .mkv, а не .mp4, и он автоматом поймет, что я хочу контейнер mkv?
>>3010721
Спасибо, помогло. MKV действительно получился с constant frame rate.
Но если я потом ремуксю его в MP4, снова вылезает эта хуйня:
Frame rate mode : Variable
Frame rate : 15.000 FPS
Minimum frame rate : 14.856 FPS
Maximum frame rate : 15.152 FPS
делал так: ffmpeg -i concatenated.mkv -codec copy remuxed.mp4
При этом длительность в миллисекундах одинаковая (в данном случае, 50.333 с)
Если же я открываю получившийся MKV в Avidemux'е и ремуксю в нем (режим для видео: copy, аудиодорожки нету), то таки получается MP4 с константным фпс:
Frame rate mode : Constant
Frame rate : 15.000 FPS
... но зато длительность превращается в 50 s 334 ms . Откуда, если с константным фпс 15.000 может получиться 50.333 с, но никак не 50.334?!
Понимаю, что это невероятная мелочь, и в принципе получившийся MP4 меня устраивает – 15.000 фпс, нет фризов, как описывал выше, везде воспроизводится – но уже просто спортивный интерес докопаться до сути проблемы.
Спасибо, помогло. MKV действительно получился с constant frame rate.
Но если я потом ремуксю его в MP4, снова вылезает эта хуйня:
Frame rate mode : Variable
Frame rate : 15.000 FPS
Minimum frame rate : 14.856 FPS
Maximum frame rate : 15.152 FPS
делал так: ffmpeg -i concatenated.mkv -codec copy remuxed.mp4
При этом длительность в миллисекундах одинаковая (в данном случае, 50.333 с)
Если же я открываю получившийся MKV в Avidemux'е и ремуксю в нем (режим для видео: copy, аудиодорожки нету), то таки получается MP4 с константным фпс:
Frame rate mode : Constant
Frame rate : 15.000 FPS
... но зато длительность превращается в 50 s 334 ms . Откуда, если с константным фпс 15.000 может получиться 50.333 с, но никак не 50.334?!
Понимаю, что это невероятная мелочь, и в принципе получившийся MP4 меня устраивает – 15.000 фпс, нет фризов, как описывал выше, везде воспроизводится – но уже просто спортивный интерес докопаться до сути проблемы.
>>3010755
ffmpeg -i result.mp4 -c copy temp.h264
ffmpeg -r 15 -i temp.h264 -c copy result2.mp4
Будет constant frame rate и контейнер mp4
ffmpeg -i result.mp4 -c copy temp.h264
ffmpeg -r 15 -i temp.h264 -c copy result2.mp4
Будет constant frame rate и контейнер mp4
>>3010760
В этом примере result.mp4 - тот файл, который получился после
ffmpeg -f concat -safe 0 -i mylist.txt -c copy concatenated.mp4
... или тот, который получился ремуксом из mkv в mp4?
ffmpeg -i concatenated.mkv -codec copy remuxed.mp4
В этом примере result.mp4 - тот файл, который получился после
ffmpeg -f concat -safe 0 -i mylist.txt -c copy concatenated.mp4
... или тот, который получился ремуксом из mkv в mp4?
ffmpeg -i concatenated.mkv -codec copy remuxed.mp4
>>3010760
Попробовал, теперь вылезла другая ебала в получившемся mp4:
Duration : 50 s 200 ms
Source duration : 50 s 333 ms
пиздец компьютеры были ошибкой
Попробовал, теперь вылезла другая ебала в получившемся mp4:
Duration : 50 s 200 ms
Source duration : 50 s 333 ms
пиздец компьютеры были ошибкой
Сап двач. Вырезал фрагмент из фильма таким вот нехитрым способом ffmpeg -i 123.mkv -ss xx:xx:xx -to xx:xx:xx -c copy 321.mkv и почему-то первые 3 секунды заруинены, что может быть не так? Если проиграть через vlc, то звук идет с самого начала, но картинка появляется только через 3 секунды, mpv же сразу начинает с этих 3 секунд проигрывать.
>>3010993
Насчет именно ффмпега не знаю, но в целом проблема в том, что в кодировании видео (почти) любым кодеком некоторые кадры - так называемые ключевые - сохраняются полностью, а остальные - только как разница между этим кадром и предыдущим. Поэтому если у тебя поврежден (или вовсе отсутствует) ключевой кадр, все остальные кадры до следующего ключевого будут также повреждены.
Если ффмпег насильно разрезает видео ровно по указанному таймкоду, то, скорее всего, начало фрагмента попадает на обычный (не ключевой) кадр, поэтому наблюдается то, что ты описал. Нужно резать с ключевого кадра, если хочешь вырезать без перекодирования.
Как посмотреть точный номер ближайшего ключевого кадра - хз, думаю, тебе кто-нибудь подскажет для ффмпега, но вообще лично я для вырезания кусков из фильмов использую MKVToolNix, в нем принудительно режется начиная с ключевого кадра.
Насчет именно ффмпега не знаю, но в целом проблема в том, что в кодировании видео (почти) любым кодеком некоторые кадры - так называемые ключевые - сохраняются полностью, а остальные - только как разница между этим кадром и предыдущим. Поэтому если у тебя поврежден (или вовсе отсутствует) ключевой кадр, все остальные кадры до следующего ключевого будут также повреждены.
Если ффмпег насильно разрезает видео ровно по указанному таймкоду, то, скорее всего, начало фрагмента попадает на обычный (не ключевой) кадр, поэтому наблюдается то, что ты описал. Нужно резать с ключевого кадра, если хочешь вырезать без перекодирования.
Как посмотреть точный номер ближайшего ключевого кадра - хз, думаю, тебе кто-нибудь подскажет для ффмпега, но вообще лично я для вырезания кусков из фильмов использую MKVToolNix, в нем принудительно режется начиная с ключевого кадра.
>>3011058
Так и должно, потому что там ключевой кадр
> Получается обратная ситуация, видео начинает проигрываться на 5 секунд раньше, а точнее само видео стало длиннее на 5 секунд, но ничего не повреждено
Так и должно, потому что там ключевой кадр
>>3011109
Т.е мне нужно взять весь фильм целиком и перекодировать его в шемб, а только потом уже нарезать?
Т.е мне нужно взять весь фильм целиком и перекодировать его в шемб, а только потом уже нарезать?
>>3011112
Вот так ебана
ffmpeg -i 123.mkv -ss xx:xx:xx -to xx:xx:xx -c copy 321.mkv
А пишешь
ffmpeg -ss xx:xx:xx -to xx:xx:xx -i 123.mkv -c:v libx264 -preset slow -c:a copy 321.mkv
Вот так ебана
ffmpeg -i 123.mkv -ss xx:xx:xx -to xx:xx:xx -c copy 321.mkv
А пишешь
ffmpeg -ss xx:xx:xx -to xx:xx:xx -i 123.mkv -c:v libx264 -preset slow -c:a copy 321.mkv
>>3011112
Нет, ты можешь вырезать кусок без перекодирования с небольшим запасом (секунд 5-10 до нужной тебе точки и секунды 3 после). После чего работать уже с этим небольшим файлом и делать с ним что угодно, в т.ч. взять из него кусок ровно-ровно с нужного тебе кадра и закодировать его в вебм, ну или что там тебе надо.
Вебм (вернее, кодек внутри вебм) тоже содержит в себе ключевые кадры и обычные кадры. Практически все кодеки для повседневного применения так устроены. Это не баг, это фича.
Нет, ты можешь вырезать кусок без перекодирования с небольшим запасом (секунд 5-10 до нужной тебе точки и секунды 3 после). После чего работать уже с этим небольшим файлом и делать с ним что угодно, в т.ч. взять из него кусок ровно-ровно с нужного тебе кадра и закодировать его в вебм, ну или что там тебе надо.
Вебм (вернее, кодек внутри вебм) тоже содержит в себе ключевые кадры и обычные кадры. Практически все кодеки для повседневного применения так устроены. Это не баг, это фича.
Всем спасибо, во всём разобрался
>>3011361
Это значит то, что это по использует библиотеки FFmpeg по условиям лицензии lgpl версии 2.1
Не благодари
Это значит то, что это по использует библиотеки FFmpeg по условиям лицензии lgpl версии 2.1
Не благодари
>>3011362
ffmpeg -i input.mp4 -ss 00:00 -to 11:11 -c copy output.mp4
ffmpeg -i input.mp4 -ss 00:00 -to 11:11 -c copy output.mp4
>>3011376
А че ты хотел блять? Программа использует ffmpeg, хуле тут ещё объяснять?
А че ты хотел блять? Программа использует ffmpeg, хуле тут ещё объяснять?
>>3011597
Только вот зачем воюет тот имбецил, непонятно.
Только вот зачем воюет тот имбецил, непонятно.
1 Мб, 1366x768Есть один фильм в DVD5/VTS_/Custom PAL. Нужно достать цельные:
- 2 дорожки без перекодирования в оригинальном формате (ac3)
- субтитры (хуй знает что за формат).
Как достать? Что писать?
- 2 дорожки без перекодирования в оригинальном формате (ac3)
- субтитры (хуй знает что за формат).
Как достать? Что писать?
>>3014069
Mkv extractor gui
Mkv extractor gui
У меня тут идея возникла, перевести компьютерную игру в жанре poin't click квест с озвучкой своей и на ютуб. Перевода на русский для нее нет. Не знаю только как это дело организовать.
Думаю записать просто прохождение эпизодами до определенных моментов БЕЗ микрофона и голос записывать отдельно. Как идея? Как бы вы это дело организовали?
Ну и собственно если я все таки решу делать так как сказал выше, есть какая-нибудь более lighweight альтернатива для Premiere Pro комбайна которая подойдет для этих целей? Так чтобы звук можно было записывать там же, как в премьере и вот это все.
Думаю записать просто прохождение эпизодами до определенных моментов БЕЗ микрофона и голос записывать отдельно. Как идея? Как бы вы это дело организовали?
Ну и собственно если я все таки решу делать так как сказал выше, есть какая-нибудь более lighweight альтернатива для Premiere Pro комбайна которая подойдет для этих целей? Так чтобы звук можно было записывать там же, как в премьере и вот это все.
>>3014475
Ну да, да. Только проблема в том что если переводить в реальном времени то за диалогами я не буду успевать.
Походу придется все таки использовать Premiere Pro
>называется летсплей
Ну да, да. Только проблема в том что если переводить в реальном времени то за диалогами я не буду успевать.
Походу придется все таки использовать Premiere Pro
44 Кб, 500x437>>2979843 (OP)
Поясните за AV1. В частности, его ресурсоемкость. Всюду приводят его как самый лучший по сжатию формат с графиками, показывающими его охуенность, но эту характеристику почему-то обходят стороной. В общем, попробовал я это шило и не могу понять: в чем СЕЙЧАС его профиты, в практическом плане? Скорость кодирования неоправданно низкая, даже на разогнанном до усрачки i7 последних лет, 0.2-0.3 фпс для 1080p. Профит в 30% лучшего сжатия по сравнению с VP9 не стоит таких мучений. Даже 10-минутное видео можно кодировать сутки и более, как нехуй. В этом плане напоминает разновидности чисто академических алгоритмов lossless сжатия данных, таких как PAQ: максимальное сжатие при совершенно непрактичных объемах затрачиваемого процессорного времени.
Собственно, интересует, почему именно AV1 считают массовым форматом будущего? Существуют ли уже аппаратные реализации кодирования, обеспечивающие приемлемую скорость кодирования при том же качестве и степени сжатия, какие обеспечивает референсная программная реализация (libaom)? Хотел бы увидеть список, а то инфа гуглится противоречивая.
Поясните за AV1. В частности, его ресурсоемкость. Всюду приводят его как самый лучший по сжатию формат с графиками, показывающими его охуенность, но эту характеристику почему-то обходят стороной. В общем, попробовал я это шило и не могу понять: в чем СЕЙЧАС его профиты, в практическом плане? Скорость кодирования неоправданно низкая, даже на разогнанном до усрачки i7 последних лет, 0.2-0.3 фпс для 1080p. Профит в 30% лучшего сжатия по сравнению с VP9 не стоит таких мучений. Даже 10-минутное видео можно кодировать сутки и более, как нехуй. В этом плане напоминает разновидности чисто академических алгоритмов lossless сжатия данных, таких как PAQ: максимальное сжатие при совершенно непрактичных объемах затрачиваемого процессорного времени.
Собственно, интересует, почему именно AV1 считают массовым форматом будущего? Существуют ли уже аппаратные реализации кодирования, обеспечивающие приемлемую скорость кодирования при том же качестве и степени сжатия, какие обеспечивает референсная программная реализация (libaom)? Хотел бы увидеть список, а то инфа гуглится противоречивая.
>>3015305
это формат на прекрасные технологии будущего, когда пека увеличит меню можность.
сейчас можность пека - детский лепет для av1
я хочу попробовать h.266 vvc, к которому никак нормальных утилит без пердолинга не изобретут
это формат на прекрасные технологии будущего, когда пека увеличит меню можность.
сейчас можность пека - детский лепет для av1
я хочу попробовать h.266 vvc, к которому никак нормальных утилит без пердолинга не изобретут
>>3015305
Это все кал
Лучше h264 пока нет
Он быстрый, он распространен, минус что надо битрейта на 30-40% наваливать, с учетом развития 5G сетей это не проблема
Для 4К контента h265, он хорош, но слишком дорог для индустрии
Это все кал
Лучше h264 пока нет
Он быстрый, он распространен, минус что надо битрейта на 30-40% наваливать, с учетом развития 5G сетей это не проблема
Для 4К контента h265, он хорош, но слишком дорог для индустрии
>>3015342
пока мощности пк дорастут до av1 пропускная способность сетей и самое главное - их дешевизна станет такой что будет абсолютно похуй кто сколько жмёт.
пока мощности пк дорастут до av1 пропускная способность сетей и самое главное - их дешевизна станет такой что будет абсолютно похуй кто сколько жмёт.
135 Кб, 500x705>>3015342
Ящитаю, никогда ПК не осилит реализацию AV1 на уровне референсного соотношения битрейта/качества, выдаваемого libaom. Даже всякие серверные камни с 300+ Вт TDP тут мало чем помогут. Будет так же как было с VP9: например, intel добавили в свои камни аппаратный энкодер, который кодирует очень быстро, но сжатие очень плохое, файл будет на ~60% больше размером чем программный энкод с libvpx-vp9, при том же качестве видео. От чего профиты формата в значительной мере нивелируются.
>>3015372
h264 скоро уже 20 лет будет, между прочим. Он как mp3 в сфере аудио. Плюсы и минусы соответствующие.
>>3015484
Не согласен. Гугл и нетфликс не стали бы вкладывать вагоны денег в разработку AV1, если бы не было значительных экономических профитов от пониженного битрейта. Учитывая объемы трафика и постоянный рост популярности стриминговых сервисов, их можно понять. А энкод для всяких ютубов быстро и эффективно делается на ASIC'ах, недоступных массовому рынку.
Ящитаю, никогда ПК не осилит реализацию AV1 на уровне референсного соотношения битрейта/качества, выдаваемого libaom. Даже всякие серверные камни с 300+ Вт TDP тут мало чем помогут. Будет так же как было с VP9: например, intel добавили в свои камни аппаратный энкодер, который кодирует очень быстро, но сжатие очень плохое, файл будет на ~60% больше размером чем программный энкод с libvpx-vp9, при том же качестве видео. От чего профиты формата в значительной мере нивелируются.
>>3015372
h264 скоро уже 20 лет будет, между прочим. Он как mp3 в сфере аудио. Плюсы и минусы соответствующие.
>>3015484
Не согласен. Гугл и нетфликс не стали бы вкладывать вагоны денег в разработку AV1, если бы не было значительных экономических профитов от пониженного битрейта. Учитывая объемы трафика и постоянный рост популярности стриминговых сервисов, их можно понять. А энкод для всяких ютубов быстро и эффективно делается на ASIC'ах, недоступных массовому рынку.
>>2985303
Может это связано с тем, что 9700 это ядра скайлейк 2015 года разлива? А на дворе как бы 2021
> Одноядерная скорость какого-нибудь говно7 4770 и говно7 9700 всего лишь 25%
> а промежуток выхода около 7 лет
Может это связано с тем, что 9700 это ядра скайлейк 2015 года разлива? А на дворе как бы 2021
>>3015581
А какие экономические выгоды от видео, которые пользователь не может посмотреть ввиду сложности декодирования? Профит тут скорее для тех, кто может себе позволить 32к телевизор и ферму для декодирования 32к видео в реальном реалтайм времени, чтобы подрочить на чёткость. А смешные видео с котиками как казали в 480p на ультрафасте, так и будут казать, не смотря на то, что можно кратно сэкономить трафика.
> Не согласен. Гугл и нетфликс не стали бы вкладывать вагоны денег в разработку AV1, если бы не было значительных экономических профитов от пониженного битрейта
А какие экономические выгоды от видео, которые пользователь не может посмотреть ввиду сложности декодирования? Профит тут скорее для тех, кто может себе позволить 32к телевизор и ферму для декодирования 32к видео в реальном реалтайм времени, чтобы подрочить на чёткость. А смешные видео с котиками как казали в 480p на ультрафасте, так и будут казать, не смотря на то, что можно кратно сэкономить трафика.
>>3015295
Jpg не поддерживает сжатие без потерь. Лучшее качество это 100%, но оно с очень маленькими потерями
>>3015305
AV1 не стоит на месте. Постоянно вводятся улучшения ускоряющие кодирование или улучшающие качество при таком же времени. Создаются новые кодировщики, которые работают ещё быстрее (rav1e, svt-av1). При некоторых настройках они уже обгоняют x265 по скорости. Дай этому кодеку время, и он оправдает себя.
VP9 не развивается, он давно заброшен. Av1 кодирует намного лучше и быстрее него. Справедливее сравнивать с x265
Jpg не поддерживает сжатие без потерь. Лучшее качество это 100%, но оно с очень маленькими потерями
>>3015305
AV1 не стоит на месте. Постоянно вводятся улучшения ускоряющие кодирование или улучшающие качество при таком же времени. Создаются новые кодировщики, которые работают ещё быстрее (rav1e, svt-av1). При некоторых настройках они уже обгоняют x265 по скорости. Дай этому кодеку время, и он оправдает себя.
> Профит в 30% лучшего сжатия по сравнению с VP9 не стоит таких мучений
VP9 не развивается, он давно заброшен. Av1 кодирует намного лучше и быстрее него. Справедливее сравнивать с x265
>>3015667
Лолшто? AV1 поддерживается всеми более-менее актуальными браузерами, плеерами и устройствами последних 2-3 лет, и практически всеми новыми.
>>3015682
На том же железе? Нет. Это так не работает.
Сравни их с libaom по битрейту при том же качестве. Это компромиссы, чудес не бывает.
Совсем ебанулся? Его не "забросили", а финализировали. С целью чтобы все будущие программно-аппаратные энкодеры и декодеры были полностью совместимы друг с другом. Так рано или поздно делают с любым массовым форматом. Фактически, до финализации - это не готовый продукт.
AV1, безусловно, еще ждут допилы, но до того же VP9 ему как до Луны, в плане скорости он уступает на пару порядков, и никогда не приблизится. VP9 еще много лет останется стандартом де-факто для многих современных онлайн видеосервисов.
>не может посмотреть ввиду сложности декодирования?
Лолшто? AV1 поддерживается всеми более-менее актуальными браузерами, плеерами и устройствами последних 2-3 лет, и практически всеми новыми.
>>3015682
>ускоряющие кодирование или улучшающие качество при таком же времени
На том же железе? Нет. Это так не работает.
>Создаются новые кодировщики, которые работают ещё быстрее (rav1e, svt-av1)
Сравни их с libaom по битрейту при том же качестве. Это компромиссы, чудес не бывает.
>VP9 не развивается, он давно заброшен.
Совсем ебанулся? Его не "забросили", а финализировали. С целью чтобы все будущие программно-аппаратные энкодеры и декодеры были полностью совместимы друг с другом. Так рано или поздно делают с любым массовым форматом. Фактически, до финализации - это не готовый продукт.
AV1, безусловно, еще ждут допилы, но до того же VP9 ему как до Луны, в плане скорости он уступает на пару порядков, и никогда не приблизится. VP9 еще много лет останется стандартом де-факто для многих современных онлайн видеосервисов.
>>3015757
Ты очень слабо представляешь себе процент владельцев устройств "последних 2-3 лет" от общего числа пользователей, а что-то вроде 2650v2 дропает кадры всеми своими 16 потоками от 1080p av1
> плеерами и устройствами последних 2-3 лет
Ты очень слабо представляешь себе процент владельцев устройств "последних 2-3 лет" от общего числа пользователей, а что-то вроде 2650v2 дропает кадры всеми своими 16 потоками от 1080p av1
>>3015757
Это так работает
Вполне сравнимо, svt совсем немного хуже, но намного быстрее
Ты что несёшь, поехавший? Причём тут финализация? Av1 давно финализировали, но эндодеры продолжают допиливаться. Хуя ты шизоид
Он уже давно обогнал vp9, и в скорости кодирования, и в качестве, и в удобстве использования
> На том же железе? Нет. Это так не работает.
Это так работает
> Сравни их с libaom по битрейту при том же качестве. Это компромиссы, чудес не бывает.
Вполне сравнимо, svt совсем немного хуже, но намного быстрее
> Совсем ебанулся? Его не "забросили", а финализировали. С целью чтобы все будущие программно-аппаратные энкодеры и декодеры были полностью совместимы друг с другом. Так рано или поздно делают с любым массовым форматом. Фактически, до финализации - это не готовый продукт.
Ты что несёшь, поехавший? Причём тут финализация? Av1 давно финализировали, но эндодеры продолжают допиливаться. Хуя ты шизоид
> AV1, безусловно, еще ждут допилы, но до того же VP9 ему как до Луны, в плане скорости он уступает на пару порядков, и никогда не приблизится. VP9 еще много лет останется стандартом де-факто для многих современных онлайн видеосервисов.
Он уже давно обогнал vp9, и в скорости кодирования, и в качестве, и в удобстве использования
>>2979843 (OP)
Какой кодек эффективнее всего подходит для сжатия музыки с наименьшими потерями - aac или opus? Может быть ogg? Возможно ли улучшение сжатия и уменьшение потерь при использовании сторонних енкодеров, или ffmpeg жмёт хорошо? Если кодек не поддерживает частоту дискретизации оригинального файла, нужно ли перед кодированием этим кодеком менять частоту дискретизации у файла, и если да, то в каком ПО?
Какой кодек эффективнее всего подходит для сжатия музыки с наименьшими потерями - aac или opus? Может быть ogg? Возможно ли улучшение сжатия и уменьшение потерь при использовании сторонних енкодеров, или ffmpeg жмёт хорошо? Если кодек не поддерживает частоту дискретизации оригинального файла, нужно ли перед кодированием этим кодеком менять частоту дискретизации у файла, и если да, то в каком ПО?
24 Кб, 439x281>>3018150
qaac
tvbr q100-127
https://github.com/nu774/makeportable
Скачиваешь сам qaac, батник, cкачиваешь айтюнс, скачаный айтюнс кидаешь в папку с батником, запускаешь батник. Далее в папку на скрине кидаешь qaac. Устанавливаем фубар, указываем где кодер, кодируем
qaac
tvbr q100-127
https://github.com/nu774/makeportable
Скачиваешь сам qaac, батник, cкачиваешь айтюнс, скачаный айтюнс кидаешь в папку с батником, запускаешь батник. Далее в папку на скрине кидаешь qaac. Устанавливаем фубар, указываем где кодер, кодируем
>>3018150
В случае с opus, ffmpeg именно что сторонний, за кодирование opus отвечает opustools.
https://opus-codec.org/downloads/
Если пугает консолька, то можешь в фубаре добавить этот кодировщик с параметрами и всё делать мышкой.
Рекомендации по параметрам здесь:
https://audiophilesoft.ru/load/coders_utils/opus/7-1-0-66
> Возможно ли улучшение сжатия и уменьшение потерь при использовании сторонних енкодеров
В случае с opus, ffmpeg именно что сторонний, за кодирование opus отвечает opustools.
https://opus-codec.org/downloads/
Если пугает консолька, то можешь в фубаре добавить этот кодировщик с параметрами и всё делать мышкой.
Рекомендации по параметрам здесь:
https://audiophilesoft.ru/load/coders_utils/opus/7-1-0-66
>>3018150
Opus лучший вариант, лучше только xhe-aac
Желательно поменять с помощью Sox, немного лучше качество. Это работает прям в ffmpeg, одну команду дописать
>>3018219
Ебанутый, зачем ты высираешь инструкцию когда есть готовый архив? https://audiophilesoft.ru/load/coders_utils/qaac/7-1-0-50
И вообще есть сомнения что aac лучше opus, судя по многочисленным тестам с hydrogenaudio
>>3018232
Ничего подобного, там используется один и тот же энкодер
Opus лучший вариант, лучше только xhe-aac
> Если кодек не поддерживает частоту дискретизации оригинального файла, нужно ли перед кодированием этим кодеком менять частоту дискретизации у файла, и если да, то в каком ПО?
Желательно поменять с помощью Sox, немного лучше качество. Это работает прям в ffmpeg, одну команду дописать
>>3018219
Ебанутый, зачем ты высираешь инструкцию когда есть готовый архив? https://audiophilesoft.ru/load/coders_utils/qaac/7-1-0-50
И вообще есть сомнения что aac лучше opus, судя по многочисленным тестам с hydrogenaudio
>>3018232
> В случае с opus, ffmpeg именно что сторонний, за кодирование opus отвечает opustools.
Ничего подобного, там используется один и тот же энкодер
>>3018235
latest version v2.72
latest version v2.72
>>3005302
Тоже юзаю этот гуи
Тоже юзаю этот гуи
> лучше только xhe-aac
чем ты его кодировать будешь?
> есть сомнения что aac лучше opus
у opus был обсёр по некоторым киллер семплам до версии libopus 1.3 на любом битрейте вплоть до 256 kbps.
> Ничего подобного, там используется один и тот же энкодер
Ты путаешь. libopus это сторонний кодировщик который можно скомпилировать с ffmpeg. Также у самого ffmpeg есть свой экспериментальный кодировщик opus.
>>2988389
>>2988393
Тикток лучше скачивать через утилиту из тикток треда https://2ch.hk/media/res/159114.html (М)
Она как-то сурсы достаёт, вот https://ssstik.io и их прога
>>2988393
Тикток лучше скачивать через утилиту из тикток треда https://2ch.hk/media/res/159114.html (
М)Она как-то сурсы достаёт, вот https://ssstik.io и их прога
>>2988498
Ты так говоришь, как будто это две несвязанные вещи
Ты так говоришь, как будто это две несвязанные вещи
>>3018345
Easy CD ripper
Этот сторонний является официальным, точно такой же как в opustools. Этот экспериментальный не используется
> чем ты его кодировать будешь?
Easy CD ripper
> Ты путаешь. libopus это сторонний кодировщик который можно скомпилировать с ffmpeg. Также у самого ffmpeg есть свой экспериментальный кодировщик opus.
Этот сторонний является официальным, точно такой же как в opustools. Этот экспериментальный не используется
>>3018560
Ты бы ещё написал ffmpeg или какой нибудь Total Video Converter. Я тебя спрашивал про encoder формата xhe-aac, а не про converter.
> Easy CD ripper
Ты бы ещё написал ffmpeg или какой нибудь Total Video Converter. Я тебя спрашивал про encoder формата xhe-aac, а не про converter.
тест
>>3018563
Ты долбоеб сука, он может конвертировать файлы, не обязательно с диска. Совершенно любые. В нём встроены энкодеры от Fraunhofer
Ты долбоеб сука, он может конвертировать файлы, не обязательно с диска. Совершенно любые. В нём встроены энкодеры от Fraunhofer
https://www.poikosoft.com/
Этот конкретно
Этот конкретно
>>3018641
>>3018644
Шиз, не понимающий разницу между encoder и converter, успокойся. Сейчас я сам тебе её разжую.
Encoder это программа или библиотека которая преобразует несжатые данные (WAV PCM) в данные закодированные (сжатые) в определенном формате. Encoder не умеет декодировать данные других типов, так как не содержит их декодеров.
Converter это программа, которая содержит в себе множество encoders, decoders, и управляет процессами декодирования и кодирования. Множество встроенных декодеров позволяет конвертеру принимать на вход данные из множества форматов, а множество встроенных encoders позволяет конвертеру выдавать на выходе файл одного из множества форматов.
>>3018644
Шиз, не понимающий разницу между encoder и converter, успокойся. Сейчас я сам тебе её разжую.
Encoder это программа или библиотека которая преобразует несжатые данные (WAV PCM) в данные закодированные (сжатые) в определенном формате. Encoder не умеет декодировать данные других типов, так как не содержит их декодеров.
Converter это программа, которая содержит в себе множество encoders, decoders, и управляет процессами декодирования и кодирования. Множество встроенных декодеров позволяет конвертеру принимать на вход данные из множества форматов, а множество встроенных encoders позволяет конвертеру выдавать на выходе файл одного из множества форматов.
>>3018742
И получается, что converter может выполнять функции encoder, поскольку содержит его?
И получается, что converter может выполнять функции encoder, поскольку содержит его?
>>3018747
Тогда почему ты горишь когда тебе предлагают выполнять функции encoder converter'ом?
Тогда почему ты горишь когда тебе предлагают выполнять функции encoder converter'ом?
>>3018764
Каким енкодером ты будешь кодировать xhe-aac?
Каким енкодером ты будешь кодировать xhe-aac?
>>3018806
Вот это легче найти, на разных сайтах.
Вот это легче найти, на разных сайтах.
av1 охуенен, ужал все свои вебмки. Осталось, чтобы бибизяна прикрутила наконец превью
>>3019057
И где-то даже шакалы пропали
И где-то даже шакалы пропали
274 Кб, 964x712>>3020251
Проверяли уже с сжатие-тредах.
Повторное пережатие шкальных картинок как минимум не портит результат, как максимум - может сгладить артефакты старых алгоритмов.
Проверяли уже с сжатие-тредах.
Повторное пережатие шкальных картинок как минимум не портит результат, как максимум - может сгладить артефакты старых алгоритмов.
>>3020260
Что ты несёшь, ебанутый? Какое ещё сглаживание артефактов? Полнейшее мыло оно только можно сделать, ничего более
Что ты несёшь, ебанутый? Какое ещё сглаживание артефактов? Полнейшее мыло оно только можно сделать, ничего более
>>3020260
Всё так, взял шакальную 320p шебмку, на 123 перезжатии забрал 4к. В этих новых алгоритмах сжатия с потерями происходят отрицательные потери.
Всё так, взял шакальную 320p шебмку, на 123 перезжатии забрал 4к. В этих новых алгоритмах сжатия с потерями происходят отрицательные потери.
>>3020264
Суть в том, что это мыло гарантированно несёт не меньше инфы, чем шакальный оригинал. Этого знания достаточно, чтобы смело пережимать паки.
>Полнейшее мыло
Суть в том, что это мыло гарантированно несёт не меньше инфы, чем шакальный оригинал. Этого знания достаточно, чтобы смело пережимать паки.
>>3020834
Оно гарантировано несёт меньше инфы, чем оригинал. Потеря поколений, не, не слышал. Покормил
> Суть в том, что это мыло гарантированно несёт не меньше инфы, чем шакальный оригинал. Этого знания достаточно, чтобы смело пережимать паки.
Оно гарантировано несёт меньше инфы, чем оригинал. Потеря поколений, не, не слышал. Покормил
>>3021000
Cейчас взял vp9 и переконвертировал в av1. На первом графике видно, что общее качество видео стало незначительно, но лучше. Это как раз и есть исключения дефектов алгоритма, как я полагаю. Потом уже, отвечая на это >>3020266 , это и так очевидно, что никакого чуда не происходит и при повторном конвертировании av1 уже потеря качества.
К слову, тот факт, что при пережатии в av1 может вдруг стать меньше шакалов, виден невооруженным глазом с некоторыми файлами. Однако, не всегда это идет на пользу
Cейчас взял vp9 и переконвертировал в av1. На первом графике видно, что общее качество видео стало незначительно, но лучше. Это как раз и есть исключения дефектов алгоритма, как я полагаю. Потом уже, отвечая на это >>3020266 , это и так очевидно, что никакого чуда не происходит и при повторном конвертировании av1 уже потеря качества.
К слову, тот факт, что при пережатии в av1 может вдруг стать меньше шакалов, виден невооруженным глазом с некоторыми файлами. Однако, не всегда это идет на пользу
>>3020942
сука, из какого ты манямирка?
как блять ухудшением качества можно добиться улучшения качества?
сука, из какого ты манямирка?
как блять ухудшением качества можно добиться улучшения качества?
Петушиное горение от прекрасного AV1 бесценно
>>3021115
Это дефекты алгоримов сравнения, которые мыло считают меньшим дефектом, чем квадрат.
У тебя 4 картинки в пост помещаются, можно было и добавить для невооружённых глаз.
> Это как раз и есть исключения дефектов алгоритма
Это дефекты алгоримов сравнения, которые мыло считают меньшим дефектом, чем квадрат.
> виден невооруженным глазом с некоторыми файлами
У тебя 4 картинки в пост помещаются, можно было и добавить для невооружённых глаз.
>>3021127
Полагаю, для некоторых замена блочности и пикселей на мыльцо это действительно в каком-то роде маленькая чудо. Есть же солнечные люди, которые ветерочку радуются, или там, скажем, дождичку, кто сказал что в мире софтваре не может быть подобных?
> кукарекаем о магии
Полагаю, для некоторых замена блочности и пикселей на мыльцо это действительно в каком-то роде маленькая чудо. Есть же солнечные люди, которые ветерочку радуются, или там, скажем, дождичку, кто сказал что в мире софтваре не может быть подобных?
>>3021000
Большая часть этих дефектов не вписываются в модель компрессора и отбрасываются.
>эти дефекты не только остаются
Большая часть этих дефектов не вписываются в модель компрессора и отбрасываются.
>>3021153
Нахуй ты так прикладываешь модель компрессора ав1, своим инсинуациями, что он якобы шлёт нахуй пространственный анализ и сам выбирает что ему жать западло.
Нахуй ты так прикладываешь модель компрессора ав1, своим инсинуациями, что он якобы шлёт нахуй пространственный анализ и сам выбирает что ему жать западло.
>>3021150
Как и наши глаза в некоторых случаях. И ты можешь сколько угодно читать мантры, что это не так и рассказывать свои фантазии про речки, но для меня в самом прямом смысле этого слова очевидно, что абу №2 выглядит лучше, чем абу №1
>которые мыло считают меньшим дефектом, чем квадрат.
Как и наши глаза в некоторых случаях. И ты можешь сколько угодно читать мантры, что это не так и рассказывать свои фантазии про речки, но для меня в самом прямом смысле этого слова очевидно, что абу №2 выглядит лучше, чем абу №1
551 Кб, 656x586>>3021150
This. Но мыло действительно меньший дефект - чем блочность. Просто ты к ней привык, как протобумеры привыкли к интелейсу.
>Это дефекты алгоримов сравнения
This. Но мыло действительно меньший дефект - чем блочность. Просто ты к ней привык, как протобумеры привыкли к интелейсу.
>>3021156
Ебать ты мылорождённый, ну жал бы и первый ролик с blur(1), раз такой дегенерат.
Ебать ты мылорождённый, ну жал бы и первый ролик с blur(1), раз такой дегенерат.
>>3021157
Вижу несостыковочку в логическом посыле
>дефекты алгоримов сравнения
>Но мыло действительно меньший дефект
Вижу несостыковочку в логическом посыле
>>3021155
Потц, модель строится на несжатом видео. Несжатому видео не свойственны высокочастотные переходы между блоками. Эти высокочастотные переходы модель отправляет на мороз.
Потц, модель строится на несжатом видео. Несжатому видео не свойственны высокочастотные переходы между блоками. Эти высокочастотные переходы модель отправляет на мороз.
>>3021159
Я согласен с тем, что метрики неидеальны. Но метрика которая даёт мылу больше очков, чем блочной ряби - валидная метрика.
Я согласен с тем, что метрики неидеальны. Но метрика которая даёт мылу больше очков, чем блочной ряби - валидная метрика.
46 Кб, 147x528>>3021160
> Потц, модель строится на несжатом видео. Несжатому видео не свойственны высокочастотные переходы между блоками. Эти высокочастотные переходы модель отправляет на мороз.
>>3021158
Ты принимаешь границы блоков за резкость. Это фейковая резкость, она к содержимому ролика не имеет отношения.
Ты принимаешь границы блоков за резкость. Это фейковая резкость, она к содержимому ролика не имеет отношения.
>>3021165
Это и не утверждалось, долбоеб. Ты никакими средствами не добьешься сопоставимого качества при соответствующем битрейте
Это и не утверждалось, долбоеб. Ты никакими средствами не добьешься сопоставимого качества при соответствующем битрейте
>>3021169
Дегенерат, речь шла про исключение дефектов устаревших алгоритмов, а не "восстановление дефектов". Опять ты выдаешь желаемое за действительное и копротивляешься, пока тебя обоссывает весь тред
Дегенерат, речь шла про исключение дефектов устаревших алгоритмов, а не "восстановление дефектов". Опять ты выдаешь желаемое за действительное и копротивляешься, пока тебя обоссывает весь тред
>>3021171
Вот только он их не исключает, ебанат, а просто жмёт, как ему и положено.
> исключение дефектов
Вот только он их не исключает, ебанат, а просто жмёт, как ему и положено.
118 Кб, 630x375>>3021164
Здесь от высокочастотного перехода и не осталось ничего, о чём и речь.
Здесь от высокочастотного перехода и не осталось ничего, о чём и речь.
>>3021172
Терминология обосравшейся манюни в цвете. Можешь теперь закрыть вкладку от стыда и больше сюда не заходить
>не срет а какает
Терминология обосравшейся манюни в цвете. Можешь теперь закрыть вкладку от стыда и больше сюда не заходить
>>3021170
Когда дефект - это видимая невооружённым взглядом блочность прямиком из 98, то дефектовка таких дефектов приводит к численно подтверждённому росту метрик и визуальному улучшению.
Что ав1 из воздуха вернёт потерянную информацию - это ты сам себе додумал.
Когда дефект - это видимая невооружённым взглядом блочность прямиком из 98, то дефектовка таких дефектов приводит к численно подтверждённому росту метрик и визуальному улучшению.
Что ав1 из воздуха вернёт потерянную информацию - это ты сам себе додумал.
>>3021179
Тебе несколько раз уже продемонстрировали и доходчиво объяснили, что имеется ввиду.
Тебе несколько раз уже продемонстрировали и доходчиво объяснили, что имеется ввиду.
>>3021180
Добавление дефекта есть добавление дефекта, а что ты там имел ввиду ты маме расскажи.
Добавление дефекта есть добавление дефекта, а что ты там имел ввиду ты маме расскажи.
>>3021181
Классическое отрицалово пошло и наименование вещей так, как они еще вписываются в трещащий по швам манямир. Ну ты не волнуйся, дальше всегда следует принятие
Классическое отрицалово пошло и наименование вещей так, как они еще вписываются в трещащий по швам манямир. Ну ты не волнуйся, дальше всегда следует принятие
>>3021181
О добавление дефекта речь может идти в случае аддитивной помехи. В случае со сжатием дефект - это декомпозиция изображения и отбрасывание маловажных, по мнению модели, элементов. И в этом контексте твои наивные умозаключения становятся не столь стройными.
>Добавление дефекта
О добавление дефекта речь может идти в случае аддитивной помехи. В случае со сжатием дефект - это декомпозиция изображения и отбрасывание маловажных, по мнению модели, элементов. И в этом контексте твои наивные умозаключения становятся не столь стройными.
115 Кб, 960x630>>3021173
Что ещё спизданёшь?
Что ещё спизданёшь?
>>3021242
Был бы он в обиходе может и бахнули бы, это недостатки вп9 ютуб тебе прямо с монитора на лицо спускает и отрицать хуёвость энкодера перестали уже самые отбитые фанатики, ав1 многие даже не начинали использовать, ввиду отсутствия поддержки, да и исжили себя вебм треды, в которых велась борьба за килобайты какчества. Потому и бахать не с чего.
Был бы он в обиходе может и бахнули бы, это недостатки вп9 ютуб тебе прямо с монитора на лицо спускает и отрицать хуёвость энкодера перестали уже самые отбитые фанатики, ав1 многие даже не начинали использовать, ввиду отсутствия поддержки, да и исжили себя вебм треды, в которых велась борьба за килобайты какчества. Потому и бахать не с чего.
>>3021302
Почему изжили?
Почему изжили?
>>2979843 (OP)
Понадобилось микшировать несколько аудиофайлов в один. Использовал для этой цели sox с ключом -m - итоговый файл получился очень тихим, каждый из отдельных его исходников звучит громче. В ffmpeg с командой ffmpeg -i alex.aiff -i fred.aiff -i whisper.aiff -filter_complex "[0:0][1:0] amix=inputs=3:duration=longest" out.mp3 (вместо этих имён файлов у меня были другие, в количестве 8 штук) громкость осталась такой же тихой. Audacity предложил микшировать в моно, мне это не нужно, так как исходники в стерео. В другом редакторе получается клипинг. Есть ли способ микшировать несколько файлов с нормальной громкостью?
Понадобилось микшировать несколько аудиофайлов в один. Использовал для этой цели sox с ключом -m - итоговый файл получился очень тихим, каждый из отдельных его исходников звучит громче. В ffmpeg с командой ffmpeg -i alex.aiff -i fred.aiff -i whisper.aiff -filter_complex "[0:0][1:0] amix=inputs=3:duration=longest" out.mp3 (вместо этих имён файлов у меня были другие, в количестве 8 штук) громкость осталась такой же тихой. Audacity предложил микшировать в моно, мне это не нужно, так как исходники в стерео. В другом редакторе получается клипинг. Есть ли способ микшировать несколько файлов с нормальной громкостью?
>>3021738
Переустановить винамп.
Переустановить винамп.
сап
на левой вемб не моей внизу отображается тайтл.
через ffmpeg поставил тайтл правой вебм, но он не отображается.
что я делаю не так?
на левой вемб не моей внизу отображается тайтл.
через ffmpeg поставил тайтл правой вебм, но он не отображается.
что я делаю не так?
>>3023422
я вот об этом
я вот об этом
Существует множество алгоритмов интерполяции. Но знаете ли вы, что для интерполяции можно использовать даже JPEG?
Для этого нужно предварительно произвести интерполяция ближайшим соседом в 2 раза, а затем вручную подобрать уровень сжатия, который будет сглаживать лесенки правда, эфект от сглаживания будет нивелирован повышенной блочностью джипега.
Первая картинка сжималась с качеством 10, вторая с качеством 50.
Для этого нужно предварительно произвести интерполяция ближайшим соседом в 2 раза, а затем вручную подобрать уровень сжатия, который будет сглаживать лесенки правда, эфект от сглаживания будет нивелирован повышенной блочностью джипега.
Первая картинка сжималась с качеством 10, вторая с качеством 50.
>>3024434
Я додумался до использования пользовательской матрицы квантования для улучшения фильтрации и снижения потерь от сжатия.
Матрица квантования:
# This is table 0 (the luminance table):
4 3 2 4 99 99 99 99
3 3 3 5 99 99 99 99
3 3 4 6 99 99 99 99
3 4 6 7 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
# This is table 1 (the chrominance table):
4 5 6 12 99 99 99 99
4 5 7 13 99 99 99 99
6 6 14 99 99 99 99 99
12 13 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
Матрицы надо сохранить в текстовой файл и указать в качестве аргумента -qtables програмы cjpeg:
convert upsampled_nearest_neighbor.png ppm:- | cjpeg -qtables jpeg_qtable7.txt -sample 1x1 -quality %УРОВЕНЬ КАЧЕСТВА% -outfile test203.jpg
Первая сжималась с уровнем качества 5, вторая: 25.
>>3024480
В отм посте предсталено 2 пары картинок. Первая картинка в паре: оригинал в низком разрешени, вторая: интерполяция оригинала ближайшим соседом, пожатая джипегом. Джипег в даном случае выступает в качестве НЧ фильтра.
Я додумался до использования пользовательской матрицы квантования для улучшения фильтрации и снижения потерь от сжатия.
Матрица квантования:
# This is table 0 (the luminance table):
4 3 2 4 99 99 99 99
3 3 3 5 99 99 99 99
3 3 4 6 99 99 99 99
3 4 6 7 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
# This is table 1 (the chrominance table):
4 5 6 12 99 99 99 99
4 5 7 13 99 99 99 99
6 6 14 99 99 99 99 99
12 13 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
Матрицы надо сохранить в текстовой файл и указать в качестве аргумента -qtables програмы cjpeg:
convert upsampled_nearest_neighbor.png ppm:- | cjpeg -qtables jpeg_qtable7.txt -sample 1x1 -quality %УРОВЕНЬ КАЧЕСТВА% -outfile test203.jpg
Первая сжималась с уровнем качества 5, вторая: 25.
>>3024480
В отм посте предсталено 2 пары картинок. Первая картинка в паре: оригинал в низком разрешени, вторая: интерполяция оригинала ближайшим соседом, пожатая джипегом. Джипег в даном случае выступает в качестве НЧ фильтра.
>>3024434
Я додумался до использования пользовательской матрицы квантования для улучшения фильтрации и снижения потерь от сжатия.
Матрица квантования:
# This is table 0 (the luminance table):
4 3 2 4 99 99 99 99
3 3 3 5 99 99 99 99
3 3 4 6 99 99 99 99
3 4 6 7 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
# This is table 1 (the chrominance table):
4 5 6 12 99 99 99 99
4 5 7 13 99 99 99 99
6 6 14 99 99 99 99 99
12 13 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
Матрицы надо сохранить в текстовой файл и указать в качестве аргумента -qtables програмы cjpeg:
convert upsampled_nearest_neighbor.png ppm:- | cjpeg -qtables jpeg_qtable7.txt -sample 1x1 -quality %УРОВЕНЬ КАЧЕСТВА% -outfile test203.jpg
Первая сжималась с уровнем качества 5, вторая: 25.
>>3024480
В отм посте предсталено 2 пары картинок. Первая картинка в паре: оригинал в низком разрешени, вторая: интерполяция оригинала ближайшим соседом, пожатая джипегом. Джипег в даном случае выступает в качестве НЧ фильтра.
Я додумался до использования пользовательской матрицы квантования для улучшения фильтрации и снижения потерь от сжатия.
Матрица квантования:
# This is table 0 (the luminance table):
4 3 2 4 99 99 99 99
3 3 3 5 99 99 99 99
3 3 4 6 99 99 99 99
3 4 6 7 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
# This is table 1 (the chrominance table):
4 5 6 12 99 99 99 99
4 5 7 13 99 99 99 99
6 6 14 99 99 99 99 99
12 13 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
Матрицы надо сохранить в текстовой файл и указать в качестве аргумента -qtables програмы cjpeg:
convert upsampled_nearest_neighbor.png ppm:- | cjpeg -qtables jpeg_qtable7.txt -sample 1x1 -quality %УРОВЕНЬ КАЧЕСТВА% -outfile test203.jpg
Первая сжималась с уровнем качества 5, вторая: 25.
>>3024480
В отм посте предсталено 2 пары картинок. Первая картинка в паре: оригинал в низком разрешени, вторая: интерполяция оригинала ближайшим соседом, пожатая джипегом. Джипег в даном случае выступает в качестве НЧ фильтра.
Во что лучше конвертировать библиотеку кина? Исходники 1080p-ремуксы, на выходе должны быть те же 1080p с тем же максимально близким к ремуксу качеством. Стоит ли ждать H266 или еще каких новых кодеков?
>>3025008
Не надо их конвертировать совершенно. Исходники для того и созданны, чтобы хранить их в оригинальном качестве, без пересжатия в хлам криворукими сжимальщиками. Сразу качай сжатое говно, например с 1337 в кодеке AV1 куча раздач. И лучше в него конвертировать, с помощью av1an какого-нибудь
Не надо их конвертировать совершенно. Исходники для того и созданны, чтобы хранить их в оригинальном качестве, без пересжатия в хлам криворукими сжимальщиками. Сразу качай сжатое говно, например с 1337 в кодеке AV1 куча раздач. И лучше в него конвертировать, с помощью av1an какого-нибудь
>>3007915
бамп
бамп
>>3007915
Нет такого говна, сохраняй видео без сжатия а потом в vp9
Нет такого говна, сохраняй видео без сжатия а потом в vp9
>>3025024
подскажите, как настроить качество в av1
другой анон
у меня куча разных файлов, я их соединю в один. на вызоде будет к примеру файл 6гб в h.264.
как подобрать качество в av1?
подскажите, как настроить качество в av1
другой анон
у меня куча разных файлов, я их соединю в один. на вызоде будет к примеру файл 6гб в h.264.
как подобрать качество в av1?
Ну охуеть теперь, rav1e с настройками по умолчанию энкодит где-то в два-три раза медленнее чем libvpx vp9 и пидорасит всё в хлам в квадратики, качество несравнимо хуже.
На кого это рассчитано, лол.
На кого это рассчитано, лол.
>>3025547
На мой взгляд, решает аппаратка, а нвидиа уже запилила декодблок ав1, его продвигает ютюб и твич, а как пойдёт в массы ввс?
На мой взгляд, решает аппаратка, а нвидиа уже запилила декодблок ав1, его продвигает ютюб и твич, а как пойдёт в массы ввс?
>>3025663
да там даже программы для кодировки нормальной нет. есть какая-то, но её нужно самому компилировать из исходников
да там даже программы для кодировки нормальной нет. есть какая-то, но её нужно самому компилировать из исходников
>>3025663
VVC он не для веб-лохов, он для 8К блуреев, не боись, хорошо пойдёт, Декод HEVC запилили же. Просто браузероделы больны патентошизой, поэтому свои мыльные поделки пилят, а вот не было бы их, повторилась бы история с H.264.
>>3025866
Кодек в разработке, ебло. Этот кодек пилит серьёзный институт, сторудники которого собаку на медиа съели, это не веб-макаки говношлёпы, поэтому такая медленная разработка.
> а как пойдёт в массы ввс?
VVC он не для веб-лохов, он для 8К блуреев, не боись, хорошо пойдёт, Декод HEVC запилили же. Просто браузероделы больны патентошизой, поэтому свои мыльные поделки пилят, а вот не было бы их, повторилась бы история с H.264.
>>3025866
Кодек в разработке, ебло. Этот кодек пилит серьёзный институт, сторудники которого собаку на медиа съели, это не веб-макаки говношлёпы, поэтому такая медленная разработка.
>>3026572
Сложно запилить на аппаратном кодировщике
Сложно запилить на аппаратном кодировщике
>>3025159
Пишу сюда оптимальные crf для популярных кодеков
Avc - 24-25
HEVC -26-28 если сильно места жалко, то можно и 30-32, разницу видно только если сложные сцены и с лупой смотреть
Vp8 - 24-26
Vp9 - 26-27
AV1 - 28-30 не люблю этот кодек, почему-то нормально кодировать в него умеют только сервера ютуба, а через ффмпег получается в десять - двадцать раз медленнее, а результат такой же что у хевк
Пишу сюда оптимальные crf для популярных кодеков
Avc - 24-25
HEVC -26-28 если сильно места жалко, то можно и 30-32, разницу видно только если сложные сцены и с лупой смотреть
Vp8 - 24-26
Vp9 - 26-27
AV1 - 28-30 не люблю этот кодек, почему-то нормально кодировать в него умеют только сервера ютуба, а через ффмпег получается в десять - двадцать раз медленнее, а результат такой же что у хевк
>>3026580
Спасибо за рекомендацию, но мне так-же хотелось бы знать, как ты определил оптимальные crf?
алсо, прямо сейчас кодирую в hevc с crf 24
Спасибо за рекомендацию, но мне так-же хотелось бы знать, как ты определил оптимальные crf?
алсо, прямо сейчас кодирую в hevc с crf 24
35 Кб, 570x572>>2979843 (OP)
avc кодек на ютубе ВСЕ!
Если раньше битрейт у 1080p avc всегда был выше на 10%-40% чем у vp9, то теперь он всегда ниже на 5%-20% чем vp9
Учитывая что и раньше битрейт у avc был занижен до предела, теперь качество станет ниже плинтуса.
Интернет становится быстрее, а гугл продолжает дешманить видео
avc кодек на ютубе ВСЕ!
Если раньше битрейт у 1080p avc всегда был выше на 10%-40% чем у vp9, то теперь он всегда ниже на 5%-20% чем vp9
Учитывая что и раньше битрейт у avc был занижен до предела, теперь качество станет ниже плинтуса.
Интернет становится быстрее, а гугл продолжает дешманить видео
>>3026580
Что за хуйню ты написал? crf зависит от разрешения, а не от кодека. Он по идее не отличается для разных кодеков. более новые кодеки будут выдавать лучше картинку при таком же размере. Чем больше разрешение, тем лучше оно сжимается
https://trac.ffmpeg.org/wiki/Encode/H.264#crf
Вот неплохие значения:
RF 18-22 for 480p/576p Standard Definition
RF 19-23 for 720p High Definition
RF 20-24 for 1080p Full High Definition
RF 22-28 for 2160p 4K Ultra High Definition
Вот неплохие параметры для AV1, кодирует не супер долго, но зато можно сжать качественнее чем x265. Можешь увеличить crf. Чем сильнее сжатие, тем больше AV1 выигрывает. Какой у тебя процессор?
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 4 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 35 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 1 -an -f null -
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 4 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 35 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 2 -c:a libopus -b:a 160k -filter:a "aresample=48000:resampler=soxr:precision=33" "out.webm"
Прикладываю 6 минутное 720p видео с весом 8 мегабайт, сжатое с максимальными настройками AV1, с таким сильным сжатием практически весь текст читается! x265 вообще не вывозит такое, там кроме мыла ничего не остаётся.
>>3026606
StaxRip, куча настроек, опций, есть сравнение разных видео, очень крутая штука.
>>3026635
На каких видео ты это заметил? На новых? Даже с более низким битрейтом avc будет выглядеть лучше, он не размывает видео как ебаный vp9
Что за хуйню ты написал? crf зависит от разрешения, а не от кодека. Он по идее не отличается для разных кодеков. более новые кодеки будут выдавать лучше картинку при таком же размере. Чем больше разрешение, тем лучше оно сжимается
https://trac.ffmpeg.org/wiki/Encode/H.264#crf
Вот неплохие значения:
RF 18-22 for 480p/576p Standard Definition
RF 19-23 for 720p High Definition
RF 20-24 for 1080p Full High Definition
RF 22-28 for 2160p 4K Ultra High Definition
Вот неплохие параметры для AV1, кодирует не супер долго, но зато можно сжать качественнее чем x265. Можешь увеличить crf. Чем сильнее сжатие, тем больше AV1 выигрывает. Какой у тебя процессор?
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 4 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 35 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 1 -an -f null -
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 4 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 35 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 2 -c:a libopus -b:a 160k -filter:a "aresample=48000:resampler=soxr:precision=33" "out.webm"
Прикладываю 6 минутное 720p видео с весом 8 мегабайт, сжатое с максимальными настройками AV1, с таким сильным сжатием практически весь текст читается! x265 вообще не вывозит такое, там кроме мыла ничего не остаётся.
>>3026606
StaxRip, куча настроек, опций, есть сравнение разных видео, очень крутая штука.
>>3026635
На каких видео ты это заметил? На новых? Даже с более низким битрейтом avc будет выглядеть лучше, он не размывает видео как ебаный vp9
Я не знаю почему на этой обоссаной помойке не прикрепляется ни один ебаный файл. Чтоб ты сдох, абу мразь конченная https://dropmefiles.com/uUj2U
График с битрейтами и 8 мб файл
График с битрейтами и 8 мб файл
12 Кб, 370x298>>3026643
Так убери «Удалять exif в настройках».
> Я не знаю почему на этой обоссаной помойке не прикрепляется ни один ебаный файл.
Так убери «Удалять exif в настройках».
>>3027311
у него зарелизили пепелину(хз что это, документ какой-то), так что можно разрабы метнуться кабанчиками
у него зарелизили пепелину(хз что это, документ какой-то), так что можно разрабы метнуться кабанчиками
Тред утонул или удален.
Это копия, сохраненная 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.