Использую ffmpeg и энкодеры libx264 и h264_omx, но независимо от использованных настроек полученая картинка заметно тусклее. Если со смазыванием и/или квадратами всё понятно, то изменение яркости или цветового баланса не понятно. Единственное предположение, которое я смог найти по поисковикам - неверное определение цветового диапазона (опции -x264-params intut-range=:range= ). Проверка всех 4-х возможных вариантов tv/pc дала одинаковую потерю цветов, так что у меня кончились предположения, что может быть виновато.
Решение: опция -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709 энкодеру. Хз почему, ведь в исходном файле было явно указано Color primaries: BT.709, но энкодер этого не определил. Если указать опцию то цвет передаётся правильно, а как бонус - заметно меньше квадратов при перекодировании.
Поэтому я думаю над тем чтобы уменьшить кадр в 1,5 или 2 раза. Но разобраться со смазыванием и квадратами я смогу довольно легко, а вот чтобы цвет не терялся...
Просто ffmpeg тебе не подходит, он довольно ограниченный. Передавай из него сырые данные по трубам. тогда ты можешь работать с картинкой без каких либо ограничений и подковёрной деятельности. Это весьма просто, x264_encoder сама прелесть.
Неужели готового подходящего рипа нет? Или это кошка на которой ты тренируешься? Если 12 гигов тебе много, а совместимость и ресурсоёмкость энкода/дэкода не критичны то можешь заменить H.264 на H.265. Можно ещё 10-битный цвет использовать (вроде есть профит в сжимаемости и качестве за счёт более точных преобразований в процессе, даже если исходник 8-бит)
Естественно только 10 бит, даже x264. 12 бит пока не имеет смысла для x265, да и вроде бы не все поддерживают декодирование, так что... Качество возрастает очень серьёзно в среднем (особенно на аниме), при сжатии. В противном случае только пытаться забивать артефакты битрейтом.
Мне жалко моего большого и хорошего телевизора филипс, лучший аппаратный декодер которого это h264 уровня 4.0. И не эффективно как раз выкидывать его или хранить коллекцию в формате «читается везде ктоме вот этого».
*Забыл упомянуть про мой основной компьютер RPi3. Там тоже нет h265 и 10-бит цвета.
Так, к слову: команда «ffmpeg -i input.mov -f yuv4mpegpipe - | x265 --preset veryslow --crf 28 --y4m - -o output.265» слегка нерабочая. Насколько могу судить ffmpeg данные в конвейр выдаёт, но x265 ничего не видит и выдаёт справку.
Если нужна красивая картинка с большим битрейтом, то используется кодек theora с палитрой 444P. И чтобы гарантированно пожать в него на имеющемся линуксе, качаешь win64 сборку ffmpeg и жмёшь в вайне. Если с х264 не пошло, надо поступить также - хз с какими ограничениями собрали ffmpeg для твоего дистрибутива. Также можешь протестировать сжатие в х264 с цветовой палитрой получше стандартной, если такая фича сейчас есть - давно новые версии не тестировал.
то изменение яркости или цветового баланса не понятно.
В х264 есть жмякалка цветовых каналов: то этот кодек кодирует цвет в диапазоне 0..255, то >0..255. В видеофайле флаг ставится чтобы плеер знал, надо при воспроизведении растягивать канал до 0..255 или не надо. Если плеер про этот флаг не в курсе, то он растянет диапазон 0..255 и картинка станет слишком яркая с неправильными цветами. У тебя всё наоборот, потому надо тестировать сжатие фрагмента видео с огромным битрейтом и сравнить цвета - если там они будут нормальные, то значит твой кодировщик так плохо жмёт, качай другую сборку. В древнем mencoder с этим всё было нормально, только медленно кодировалось.
Можно ещё 10-битный цвет использовать (вроде есть профит в сжимаемости и качестве за счёт более точных преобразований в процессе, даже если исходник 8-бит)
То-то с модой на 10-битные рипы 24 минутные серии в раздачах потяжели на 100-150 метров.
Пишка, cамосборный ffmpeg. Довольно шустрая штука и качество можно сделать неплохим. Недостатки: всего одна рабочая настройка - верхний порог битрайта, лёгкое смазывание при попытке кодека компенсировать квадраты. И всё то же самое выцвечивание.
Теоретически про этот самый цветовой диапазон вычитал и попробовал прогнать все 4 возможных варианта настройки его перекодирования, и они никак не отличались. Использовал опции вида -x264-params intut-range=tv:range=pc
А есть ссылка на хороший ман к менкодеру? Надо попробовать.
Надеюсь вы сравнивали полноразмерные изображения, отодранные от страницы хостинга? Если вынести их в какой нибудь гимп, который не накладывает фильтров, и начать переключать, то разница весьма заметна.
Конечно, лёгкая гамма-коррекция плеера уведёт разницу в район ноля, но я считаю что так когдировать неправильно.
Проблема на воспроизводящей стороне при создании скриншотов, имхо. ffmpeg никак не трогает цвет и яркость при простом YUV конвертировании между контейнерами mkv-mp4.
Дело в том, что скрин еще нужно правильно сделать. Видео обычно имеет TV уровень (16-235) и формат YUV, а компьютерный монитор и графические файлы PC уровень (0-255) в формате RGB. Плеер при просмотре растягивает TV>PC. Это же он должен делать при создании скриншота. Кроме того на цвета при YUV>RGB преобразовании еще влияет колориметрия (709 или 601), которая зависит от разрешения (SD - 601, HD - 709) или прописана в свойствах видео.
Выходной файл в контейнере mp4, возможно при mp4 плеер ведет себя по другому, использует другие демультиплексторы, декодеры (аппаратные). А может ты вообще принт скрином делаешь, тогда еще видеорендер влияет.
h264_omx
Аппаратный H.264 кодер может косячить, если работает в RGB.
-f yuv4mpegpipe - |
Тоже самое можно указать в -x264opts. А если x264 в ffmpeg кастрированный, нужны пруфы.
mencoder, кодируя в x264/avi показал точно такое же падение цвета. Я ещё хотел попробовать менкодер divx/avi, но у меня ssd на ноуте накрылся, а в распбиан ставить менкодер тот ещё геморрой.
нет, никаких принтскринов. только разбор на кадры через ffmpeg. И можно было бы всё списать на какие то фильтры внутри ffmpeg, но косяк подтверждается визуально при воспроизведении тремя разными плеерами на двух видеокартах, и потенциальный косяк у ffmpeg был бы и при разборе на кадры оригинала. Но там его нет.
Я тут проверил. ffmpeg преобразовывает HD видео с 601 колориметрией. VLC тоже неправильно делает скрины. SMPlayer (mpv) правильно.
Проверь другие файлы и если будет такой же косяк, залей пару сэмплов оригинала и пережатки на какой-нибудь файлохостинг, только не на youtube. Сэмплы можно сделать в mkvtoolnix.
Тестовые сэмплы для плееров и конвертеров https://yadi.sk/d/4K6kAd6w3agoDb Обращайте внимание на зеленый цвет (колориметрия) и слегка заметная светлая полоса справа на черном фоне (уровни, смотреть лучше ночью).
ffmpeg преобразовывает HD видео с 601 колориметрией (при создании скриншота)
Правда только если колориметрия 709 явно не задана в видеопотоке (но часто так и бывает). Тогда понятно почему https://forum.videohelp.com/threads/380610-Change-in-color-while-reencoding-w... у чела цвета неправильные. По умолчанию ffmpeg не записывает информацию о колориметрии в выходной файл, а при повторном создании скриншота всегда использует 601 колориметрию (что неправильно!). Задать можно так:
потенциальный косяк у ffmpeg был бы и при разборе на кадры оригинала. Но там его нет
Ну вот оказалось ffmpeg как минимум неправильно делает скрины с нетеггированных HD (пережатки в данном случае). Это правда не означает, что и других проблем нет.
Займусь всем этим позже - оказывается важный вопрос и автонастройке тут делать нечего. Ноут сейчас мёртв, а пишке на пределе хватаеет памяти на fullHD при стандартном preset. А veryslow это 750М, вероятно даже адресовать не сможет.
Да, а проблему с данным файлом я обошёл. Теоретически. Двойное перекодирование h264 yuv420 -> apng rgb24 -> h264 yuv422 даёт легкую погрешность цвета, но сейчас её заметно только под микроскопом. Осталось выполнить это в масштабе 17Гб файла и не рассинхронизировать аудиодорожку.
