Эй, народ

Неужто никто не знает способов решения проблемы?

ну если vp9 не умеет yuvj420p то где ж этому умению взяться ? спрашивай девелоперов

Ты ищешь -vf scale=in_range=jpeg:out_range=mpeg?

в модный, стильный, молодёжный vp9. Всё замечательно

Последний раз, когда я кодировал видео, то отказался от vp9 в пользу hevc из-за его непозволительной тормознутости.

А по теме - вот: http://trac.ffmpeg.org/ticket/225 Народ вручную подкручивает контраст )

HEVC мне и самому намного больше нравится. Но раз в 15 дольше кодирует, чем vp9. При проигрывании на слабой машине загрузка процессора 100% и вылеты плеера. Но по степени сжатия и качеству HEVC превосходит всех. Однако и у vp9 свои плюсы - например, видео можно открывать и смотреть прямо в chromium`е, без плеера, да и воспроизводится «легко» - 4k на смартфоне без лагов. По ссылке уже ходил ранее - всё. что там предлагали уже попробовал (а некоторые советы 4-5 летней давности и вовсе не заводятся). Мб ещё какие варианты могут быть?

cdslow, кмк, нормальное решение предложил.

где-то в энторнетах читал пдф про сравнение кодеков h264, hevc и vp9 и там оказалось, что h264 не так уж и плох, а если учитывать скорость кодирования и декодирования, то равных ему нет.

а покажи какой командой ты кодируешь? что-то vp9 у меня не хочет качественно кодировать и на выходе полная жёппа, а ещё он не хочет использовать все ядра, даже при указании -threads 8 в ffmpeg максимум берёт два:

ffmpeg -r 60 -i png/%04d.png -c:v vp9 -crf 20 -threads 8 out.mkv

ffmpeg version 3.2

У меня ffmpeg-3.2.1 и libvpx-1.6.0. При распараллеливании кодирования на несколько потоков возможно ухудшение качества, таковы особенности (о чём гласит вики и логика). А tile-columns разделяет кадр на 6 прямоугольников и каждый обрабатывает отдельно. Потому я отключаю эти опции. Кодирую в 2 прохода:

SOURCE_FILENAME="Source1.mov"
RESULT_FILENAME="results/${SOURCE_FILENAME}.webm"


ffmpeg -i ${SOURCE_FILENAME}\
-c:v libvpx-vp9 -pix_fmt yuv420p -crf 15 -b:v 0 -tile-columns 0 -frame-parallel 0 -g 9999\
-an\
-threads 1 -speed 4 -passlogfile ${SOURCE_FILENAME} -pass 1\
-f webm -y /dev/null

ffmpeg -i ${SOURCE_FILENAME}\
-c:v libvpx-vp9 -pix_fmt yuv420p -crf 15 -b:v 0 -tile-columns 0 -frame-parallel 0 -g 9999\
-c:a libopus\
-threads 1 -speed 0 -passlogfile ${SOURCE_FILENAME} -pass 2\
-f webm ${RESULT_FILENAME}

Где почерпнуть информации:

http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide - основа основ о vp9

https://github.com/Kagami/webm.py/wiki/Notes-on-encoding-settings - полезно, чтобы просто убрать опции, которые в первой статье частенько переопределяются (значение по умолчанию в основном то, которое нужно)

К сожалению, не помогло. Вот сравнение. Оригинал слева - более насыщенный. Как видно - качество очень даже хорошее, вот только цвета из yuvj420p в yuv420p не совсем корректно перекодируются.

Да, адово медленно, у меня fps в районе 0.2 держится. Несмотря на это качество почти как в оригинале. Но думаю можно как-то использовать видеокарту для ускорения кодирования.

Кодирование в отличии от просмотра в 95% случаев идёт на проце.

Само собой разумеется)) Но, например, hevc точно можно кодировать на gpu nvidia с огромной разницей в скорости, по сравнению с процессором.

2016q4
Кодировать шебмки на проце

Спасибо большое за ссылки.

crf is the quality value (0-63 for VP9). To trigger this mode, you must use a combination of crf <q-value> and b:v 0. bv MUST be 0.

Ага, ясненько, теперь картинка норм.

Задействовать все ядра у меня так и не вышло.

-crf 15

Не сильно круто? Если оценивать битрейт, то качество 20 hevc примерно соответствует качеству 31 vp9. Если поставить 20 для vp9, то битрейт становится 18 мегабит/с против 7 для hevc, в моём случае.

Crf и битрейт связаны примерно так: на быстрых сценах битрейт сильно вырастает, на медленно изменяющихся кадрах - битрейт падает (средний), поэтому, если снимаешь со штатива свою сидящую кошку - то crf:15 вполне нормально, практически без потерь будет закодирована картинка в h.265

Ну да, в принципе, логично. Скажите, а будет ли влиять на качство и битрейт вид животного? Просто у меня собака и может поэтому такой битрейт большой.

Если собака будет лежать пузом кверху - это одно, если жарить другую собаку - другое. Поэкспериментируй.

Чтобы задействовать все ядра, надо поиграться с tile-columns, frame-parallel, g (он же kf_max_dist), speed и, соответственно, threads. По первой ссылке я где-то находил небольшую «формулу» для правильного указания значений, сейчас не могу кинуть где точно - со смартфона пишу. Но вновь повторюсь - распараллеливание сказывается на размере и качестве.

Зависит от динамичности сцен, количества одновременно отображаемых кусков цвета, их размеров и степени их разбросанности по кадру. Море с волнами и чистое небо будут иметь намного меньший битрейт, чем цветочное поле с лесом на фоне, голубым небом и бегающим пёсиком.

Ещё один полезный ресурс по vp9 - на русском. Именно там как раз есть информация, почему при кодировании не используются все ядра.

спасибо