Использую ffmpeg и энкодеры libx264 и h264_omx, но независимо от использованных настроек полученая картинка заметно тусклее. Если со смазыванием и/или квадратами всё понятно, то изменение яркости или цветового баланса не понятно. Единственное предположение, которое я смог найти по поисковикам - неверное определение цветового диапазона (опции -x264-params intut-range=:range= ). Проверка всех 4-х возможных вариантов tv/pc дала одинаковую потерю цветов, так что у меня кончились предположения, что может быть виновато.
Решение: опция -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709 энкодеру. Хз почему, ведь в исходном файле было явно указано Color primaries: BT.709, но энкодер этого не определил. Если указать опцию то цвет передаётся правильно, а как бонус - заметно меньше квадратов при перекодировании.
Я сравнил твои скриншоты. Получается первому можно верить, а второй скриншот плееры и/или скриншотеры делают в 601, вместо 709. PC/TV уровни не причем, у них другие искажения. Если ты видишь разницу и в плеерах, значит нетеггированные HD они тоже играют в 601, вместо 709, чего быть не должно. Можно добавить опции -x264opts colormatrix при кодировании, но по хорошему надо разбираться почему плееры неправильно играют, там влияет еще рендер и видеодрайвера. Я приводил ссылку на тестовые сэмплы. Так что похоже врут у тебя и ffmpeg и плееры одинаково, а с видео всё в порядке, потому что в YUV нечему портится. Поэтому я и просил залить сами видеофайлы.
оказывается важный вопрос и автонастройке тут делать нечего
Это сложная тема. У многих вообще уровни в драйверах неправильно настроены по умолчанию (изображение засвечено), такое обычно на Windows и Nvidia. А еще я замечал, если открыть одновременно два видеоплеера, один из них или оба могут немного искажать цвета.
У многих вообще уровни в драйверах неправильно настроены по умолчанию (изображение засвечено), такое обычно на Windows и Nvidia. А еще я замечал, если открыть одновременно два видеоплеера, один из них или оба могут немного искажать цвета.
В плеерах я обычно настраиваю гамму. Штатно она слегка повышена, иногда править приходится вверх или вниз. Если речь об аппаратных плеерах (в т.ч. omxplayer на пишке), то гаммы там нет, съиграть можно только монитором. А всякие vlc и *mplayer'ы просто обожают автонастройку всяких видеофильтров. И здесь уже слишком много переменных чтобы делать скриншоты с плеера. Поэтому самым достоверным я считаю кадр, выдернутый через ffmpeg в формат без потерь. И сравнивать их на одном мониторе и одном и том же просмотрщике без всяких масок (типа смазывания в eog/eom). Тут я выбрал гимп.
Получается первому можно верить, а второй скриншот плееры и/или скриншотеры делают в 601, вместо 709. PC/TV уровни не причем, у них другие искажения. Если ты видишь разницу и в плеерах, значит нетеггированные HD они тоже играют в 601, вместо 709, чего быть не должно. Можно добавить опции -x264opts colormatrix при кодировании
Вот тут я просто не знаю что это. И меньше чем за час не разберусь, по толковому мануалу на русском.
Не рекомендую такое.
Да, грязный хак. Но придётся использовать если не разберусь с -x264opts colormatrix
всякие vlc и *mplayer'ы просто обожают автонастройку всяких видеофильтров
По умолчанию там все отключено, кроме может быть деинтерлейсера, который лучше включать только при необходимости самому.
Поэтому самым достоверным я считаю кадр, выдернутый через ffmpeg в формат без потерь.
Как оказалось он не всегда корректно это делает и вообще не панацея. Самый достоверный способ, это который лично ты проверил технически на достоверность результатов на конретной системе на тестовом файле.
Тут я выбрал гимп
Я привожу скрины к разрешению экрана в png или bmp и во весь экран поочередно открываю в просмотрщике изображений viewnior.
У меня на старой встройке все шпарит в 601, я уже привык. А дискретка корректно играет в зависимости от разрешения видеофайла. Но как мне вернуть старые привычные искажения? Добавил в опции smplayer format=colormatrix=bt.601. Дело в том, что на ютубе часто делают апскейл SD>HD и о такой ерунде, как колориметрия не задумываются (даже официальные каналы), а у меня много скачано оттуда. Так что искажения на искажения дают в итоге норму как ни странно. Другой пример, релизеры на трекерах делают рипы с BD в AVI, без коррекции, в итоге рожи красно-розовые. В smplayer можно нажать 5 на цифровой клавиатуре (оттенок -4) и становится лучше (6 вернуть как было).
Решение: опция -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709 энкодеру. Хз почему, ведь в исходном файле было явно указано Color primaries: BT.709, но энкодер этого не определил. Если указать опцию то цвет передаётся правильно, а как бонус - заметно меньше квадратов при перекодировании.
Решение: опция -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709 энкодеру. Хз почему, ведь в исходном файле было явно указано Color primaries: BT.709, но энкодер этого не определил. Если указать опцию то цвет передаётся правильно, а как бонус - заметно меньше квадратов при перекодировании.
Артефактов кодирования h264 разумеется. Перекод на перекод даёт мешанину, но в данном случае энкодер точно попал в старые квадраты и кадры получились почти идентичными.
Тут половина обсуждения о том, что кто то где то неверно выбирает спецификацию по которой декодировать цвета. Так оно и было, только оказалось довольно сложно найти ту самую фолшебную опцию для моего случая.
Где то через сутки я смогу выложить получившийся кадр - я уже зачистил место от временных файлов и начал полный проход с -preset veryslow. Поищите там отличия.
Эта опция просто добавляет метаинформацию (теги/флаги) в h264 поток, предназначенную для декодера/плеера. Само видео никак не меняется, эти данные можно даже поменять без пересжатия http://forum.doom9.org/showthread.php?t=152419 Ну да основываясь на этой информации плеер/скриншотер может по другому выполнять YUV>RGB преобразование (при просмотре, создании скринов) и поэтому при просмотре могут быть другие цвета. Но вообще-то все 1080p по стандарту с флагами или без должны играться одинаково.
цвет передаётся правильно
При сжатии h264>h264 видео не покидает yuv пространства и цвет может поменяться только если насильно впихнуть фильтр -vf colormatrix=bt709:bt601 чего ffmpeg не делает без спроса даже тогда когда это надо делать (при конверсии HD<>SD)
энкодер этого не определил
Энкодер мог бы, конечно, и прописать в теги, но я заметил, что ffmpeg предпочитает не заниматься самодеятельностью.
Квадраты это удел ASP кодеков (XviD, DivX), а также MPEG1 и 2, разве x264 квадратит с включенным деблокингом при кодировании и декодировании? Насколько я знаю при недостатке битрейта он мылит.
Даже если в мануале так и написано, я уверен это не правда. У меня было 2 тестовых фрагмента, один q20 второй color701. Второй отличается от q20 только добавлением вот этой опции, оба кодировались с 0 до 750 секунды, у обоих стандартный пресет. аудиопотоки обоих перекодированы libmp3lame -aq 1. Размер q20 был 900-960М, размер color701 чуть больше гига.
Вот пример Не знаю как правильно называется. Некоторые квадраты отличаются по размеру и сдвинуты от общей сетки. Это из оригинального кадра, масштаб 800%.
З.Ы. Да собственно библиотека x264 если и умеет деблокинг, то хорошо это скрывает. Единственное где я встречал деблокинг h264 в действии, это аппаратный энкодер h264_omx на raspberry pi.
bt470bg это для SD PAL 25 fps, если что. Для NTSC 23.976/24/29.97 используется smpte170m. Хотя это тоже самое по сути (и соответствует BT.601), просто так повелось.
При даунскейле HD>SD не забывайте также добавить фильтр -vf colormatrix=bt709:bt601,scale=720:576 При апскейле SD>HD -vf colormatrix=bt601:bt709,scale=1280:720
Сначала я тоже юзал функцию телека для просмотра. Потом понял что это говно и заменил вьювер на приставку IPTV, которую с повсеместным распространением h265 буду менять на маленький ПК с пассивным охлаждением.
Я так думаю все полагаются на дефолты ffmpeg'а (при преобразованиях RGB уровни он корректирует, а цвета только в редких случаях), но разработчики Kdenlive оказались немного более профессиональны в этом вопросе.
