Потеря цвета при перекодировании видео

Запости выхлоп mediainfo для исходника и любого из результатов сжатия.

Ну и 4-8 Гб для 1080p полнометражки в h.264 по хорошему маловато будет.

Поэтому я думаю над тем чтобы уменьшить кадр в 1,5 или 2 раза. Но разобраться со смазыванием и квадратами я смогу довольно легко, а вот чтобы цвет не терялся...

Просто ffmpeg тебе не подходит, он довольно ограниченный. Передавай из него сырые данные по трубам. тогда ты можешь работать с картинкой без каких либо ограничений и подковёрной деятельности. Это весьма просто, x264_encoder сама прелесть.

исходник:

rrr@raspberrypi:/media/data/recode$ mediainfo How\ To\ Train\ Your\ Dragon\ 1.mkv 
General
Unique ID                                : 205714339186558677138962981288264600162 (0x9AC323FD3E0EE952ACC56C9B63640A62)
Complete name                            : How To Train Your Dragon 1.mkv
Format                                   : Matroska
Format version                           : Version 4 / Version 2
File size                                : 17.0 GiB
Duration                                 : 1h 37mn
Overall bit rate mode                    : Variable
Overall bit rate                         : 24.8 Mbps
Encoded date                             : UTC 2018-04-20 18:28:34
Writing application                      : mkvmerge v9.2.0 ('Photograph') 32bit
Writing library                          : libebml v1.3.3 + libmatroska v1.4.4
DURATION                                 : 01:37:51.040000000
NUMBER_OF_FRAMES                         : 183470
NUMBER_OF_BYTES                          : 164389120
_STATISTICS_WRITING_APP                  : mkvmerge v9.2.0 ('Photograph') 32bit
_STATISTICS_WRITING_DATE_UTC             : 2018-04-20 18:28:34
_STATISTICS_TAGS                         : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 1h 37mn
Bit rate mode                            : Variable
Bit rate                                 : 23.5 Mbps
Maximum bit rate                         : 30.4 Mbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 fps                                                             
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.472
Stream size                              : 16.0 GiB (95%)
Default                                  : Yes
Forced                                   : No
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

профиль high, level 4.0, qmax=20

rrr@raspberrypi:/media/data/recode$ mediainfo кпд1-q20.mp4 
General
Complete name                            : кпд1-q20.mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom
File size                                : 8.30 GiB
Duration                                 : 1h 37mn
Overall bit rate                         : 12.1 Mbps
Writing application                      : Lavf57.71.100

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.0
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 1h 37mn
Bit rate                                 : 11.5 Mbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.231
Stream size                              : 7.86 GiB (95%)
Writing library                          : x264 core 148
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=20 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

А русскоязычные мануалы по таким методам есть?

Вряд ли. Да и что там расписывать я не знаю, всё достаточно элементарно https://stackoverflow.com/questions/41131834/ffmpeg-uhd-encoding-piping-to-x2...

Для x264 мне приходилось ещё преобразовывать y4m, но в остальном то же самое. Просто читаешь ман по ffmpeg и x264.

How To Train Your Dragon 1.mkv

Неужели готового подходящего рипа нет? Или это кошка на которой ты тренируешься?
Если 12 гигов тебе много, а совместимость и ресурсоёмкость энкода/дэкода не критичны то можешь заменить H.264 на H.265. Можно ещё 10-битный цвет использовать (вроде есть профит в сжимаемости и качестве за счёт более точных преобразований в процессе, даже если исходник 8-бит)

Естественно только 10 бит, даже x264. 12 бит пока не имеет смысла для x265, да и вроде бы не все поддерживают декодирование, так что... Качество возрастает очень серьёзно в среднем (особенно на аниме), при сжатии. В противном случае только пытаться забивать артефакты битрейтом.

Нет, нужно чтобы читали аппаратные декодеры h264, 8-бит цвет. И да, предпочитаю освоить перекодирование а не найти готовый рип в нужном качестве.

Какой командой жмёшь то?

Где скриншоты до и после?

+1

Какой командой жмёшь то?

Челябинским «Трактором».

ffmpeg -i How\ To\ Train\ Your\ Dragon\ 1.mkv -map 0:0 -map 0:1 -aocdec copy -vcodec libx264 -profile:v high -level 40 -qmax 20 -f mp4 кпд1-q20.mp4

И ещё с добавлением обрезки чёрных полос: -vf crop=1920:816:0:132 и пробовал с -preset veryslow, картинка примерно та же самая, только файл меньше.

Исходный кадр, Перекодировано -profile:v high -level 40 -qmax 20 с обрезкой -vf crop

Трактор не заводится.

Серьёзно, возьми ffmpeg -i input.mov -f yuv4mpegpipe - | x265 --preset veryslow --crf 28 --y4m - -o output.265

Результат тебе понравится. Уменьшай crf по мере необходимости. Правда в 8 битном h265 смысла мало, все железки поддерживают сразу 10 битный формат. Выбери тут https://x265.readthedocs.io/en/default/cli.html#profile-level-tier

Я же уже писал, что h265 мне совсем не нужен и результатом будет чёрный экран и сообщение об ошибке.

Но ведь это же так неэффективно. В качестве альтернативы я вижу только хранение ремукса. Что тебе, пары лишних гигов жалко?

Мне жалко моего большого и хорошего телевизора филипс, лучший аппаратный декодер которого это h264 уровня 4.0. И не эффективно как раз выкидывать его или хранить коллекцию в формате «читается везде ктоме вот этого».

*Забыл упомянуть про мой основной компьютер RPi3. Там тоже нет h265 и 10-бит цвета.

Говна насобирал и теперь под него подстраиваешься. Way to go.

Так, к слову: команда «ffmpeg -i input.mov -f yuv4mpegpipe - | x265 --preset veryslow --crf 28 --y4m - -o output.265» слегка нерабочая. Насколько могу судить ffmpeg данные в конвейр выдаёт, но x265 ничего не видит и выдаёт справку.

Ну это из примера по ссылке, точные команды у меня где-то в скриптах были. Через дня 3 напомни, подскажу, если хочешь. Может быть 28.0 ?

Сделай то же для х264, главная фича что ты упустил: "--crf 28" и добавь это без пайпов прямо в команду ффмпега. Поиграйся с crf и битрейтом.

h264_omx

Опа, это на чём?

Подозреваю что аппаратный декодер на Raspberry Pi 3 у ТСа

Если нужна красивая картинка с большим битрейтом, то используется кодек theora с палитрой 444P. И чтобы гарантированно пожать в него на имеющемся линуксе, качаешь win64 сборку ffmpeg и жмёшь в вайне. Если с х264 не пошло, надо поступить также - хз с какими ограничениями собрали ffmpeg для твоего дистрибутива. Также можешь протестировать сжатие в х264 с цветовой палитрой получше стандартной, если такая фича сейчас есть - давно новые версии не тестировал.

то изменение яркости или цветового баланса не понятно.

В х264 есть жмякалка цветовых каналов: то этот кодек кодирует цвет в диапазоне 0..255, то >0..255. В видеофайле флаг ставится чтобы плеер знал, надо при воспроизведении растягивать канал до 0..255 или не надо. Если плеер про этот флаг не в курсе, то он растянет диапазон 0..255 и картинка станет слишком яркая с неправильными цветами. У тебя всё наоборот, потому надо тестировать сжатие фрагмента видео с огромным битрейтом и сравнить цвета - если там они будут нормальные, то значит твой кодировщик так плохо жмёт, качай другую сборку. В древнем mencoder с этим всё было нормально, только медленно кодировалось.

Можно ещё 10-битный цвет использовать (вроде есть профит в сжимаемости и качестве за счёт более точных преобразований в процессе, даже если исходник 8-бит)

То-то с модой на 10-битные рипы 24 минутные серии в раздачах потяжели на 100-150 метров.

На градиентах и динамике артефактов гораздо меньше, можно уменьшить битрейт. Особенно на нормальных пресетах.

я не вижу разницы в цветах

одна из них более замыленная какая-то http://screenshotcomparison.com/comparison/118737

палитра не лучшая чтобы цвета сравнивать, но вроде одинаковые

замыленная

Надо же. Обычно же от сжатия всё становится чётчe.

При нормальном сжатии картинка по-пиксельно одинаковая будет, во всяком случае визуально. Вес файла легко уменьшается в 10+ раз при этом.

Пишка, cамосборный ffmpeg. Довольно шустрая штука и качество можно сделать неплохим. Недостатки: всего одна рабочая настройка - верхний порог битрайта, лёгкое смазывание при попытке кодека компенсировать квадраты. И всё то же самое выцвечивание.

Теоретически про этот самый цветовой диапазон вычитал и попробовал прогнать все 4 возможных варианта настройки его перекодирования, и они никак не отличались. Использовал опции вида -x264-params intut-range=tv:range=pc

А есть ссылка на хороший ман к менкодеру? Надо попробовать.

Это не исходник замылен, это результат пикселизован. В динамике выглядит практически неотличимо, но статика при приближении замтно отличается.

Надеюсь вы сравнивали полноразмерные изображения, отодранные от страницы хостинга? Если вынести их в какой нибудь гимп, который не накладывает фильтров, и начать переключать, то разница весьма заметна.

Конечно, лёгкая гамма-коррекция плеера уведёт разницу в район ноля, но я считаю что так когдировать неправильно.

А есть ссылка на хороший ман к менкодеру? Надо попробовать.

http://mplayerhq.hu/design7/documentation-ru.html http://mplayerhq.hu/DOCS/HTML/ru/MPlayer.html#encoding-guide

Проблема на воспроизводящей стороне при создании скриншотов, имхо. 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 кастрированный, нужны пруфы.

с палитрой 444P

Зачем она нужна, если исходник в большинстве случаев 420?

В древнем mencoder

Нормально работает только с древним же AVI, для остального использует ffmpeg либы.

mencoder, кодируя в x264/avi показал точно такое же падение цвета. Я ещё хотел попробовать менкодер divx/avi, но у меня ssd на ноуте накрылся, а в распбиан ставить менкодер тот ещё геморрой.

нет, никаких принтскринов. только разбор на кадры через ffmpeg. И можно было бы всё списать на какие то фильтры внутри ffmpeg, но косяк подтверждается визуально при воспроизведении тремя разными плеерами на двух видеокартах, и потенциальный косяк у ffmpeg был бы и при разборе на кадры оригинала. Но там его нет.

Другой кодированный видео-файл тоже теряет цвет?

Баг оформил на ffmpeg?

нет, не оформил и надо тестировать, но визуально я такого не замечал.

может это? https://forum.videohelp.com/threads/380610-Change-in-color-while-reencoding-w...

в общем тут объясняют вроде бы https://kdenlive.org/en/project/color-hell-ffmpeg-transcoding-and-preserving-...

и тут всё достаточно прозрачно https://trac.ffmpeg.org/wiki/colorspace

разбор на кадры через ffmpeg

Простой командой?

ffmpeg -i input.mp4 output.bmp

Проверь другие файлы и если будет такой же косяк, залей пару сэмплов оригинала и пережатки на какой-нибудь файлохостинг, только не на 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 колориметрию (что неправильно!). Задать можно так:

-x264opts colormatrix=bt709:colorprim=bt709:transfer=bt709:fullrange=off

-x264opts colormatrix=bt470bg:colorprim=bt470bg:transfer=bt470bg:fullrange=off

Обновленные тестовые сэмплы (добавил tagged файлы) https://yadi.sk/d/Ol8vFdOX3agtDC

потенциальный косяк у ffmpeg был бы и при разборе на кадры оригинала. Но там его нет

Ну вот оказалось ffmpeg как минимум неправильно делает скрины с нетеггированных HD (пережатки в данном случае). Это правда не означает, что и других проблем нет.

Займусь всем этим позже - оказывается важный вопрос и автонастройке тут делать нечего. Ноут сейчас мёртв, а пишке на пределе хватаеет памяти на fullHD при стандартном preset. А veryslow это 750М, вероятно даже адресовать не сможет.

Да, а проблему с данным файлом я обошёл. Теоретически. Двойное перекодирование h264 yuv420 -> apng rgb24 -> h264 yuv422 даёт легкую погрешность цвета, но сейчас её заметно только под микроскопом. Осталось выполнить это в масштабе 17Гб файла и не рассинхронизировать аудиодорожку.