This was a regularly scheduled release with improvements in performance, major improvements in memory usage, and improved psy-rd behavior.
There were a few of new options introduced:
—cu-stats, x265_param.bLogCuStats — enabling logging of CU stats (for R&D purposes only)
—hrd, x265.bEmitHRDSEI — enable HRD SEI signaling (use this option to add Hypothetical Reference Decoder information into the HEVC bitstream, in order to comply with HRD specifications)
—ipratio/—pbratio were exposed to the CLI
—lambda-file — allows experimentation with lambda tables (for R&D purposes only — this should not be needed for normal production encoding purposes)
Plus a number of options added for multi-pass encoding (incomplete).
Попробовал кодировать 8bit видео кодеком с повышенной битовой глубиной, пишет «forcing conversion to YV12»,а профиль показывает main10 т. е. как я понимаю к 8bit видео будут применяться технологии профиля main10, асимметричное предсказание вместо симметричного, неквадратные преобразования, ALF.если так то даже 8bit видео должно смотреться лучше в профилеmain10, я прав?
да, и смотреться лучше, и сохранятся более точно, и размером меньше при условии одинакового качества по сравнению с 8 бит.
но вроде как на данный момент нет честного декодера для m10p, во всяком случае я не встречал.
например для 264@хай10 есть madVR
а для 265@майн10 — официально нет, текущие декодеры дебандят 10бит к 8.
хотя madVR и кушает 265@майн10, но из оврлея не понятно — преобразует ли он в 8бит или нет;
при сравнении скринов сделанных через другие декодеры, радикальных отличий в колориметрии не наблюдается, но вот размер скринов у мадвра самый толстый… (возможно это косвенный намёк на честные 10 бит).
Я имел ввиду 8bit видео пожатое в Main10, как я вас понял «http://x265.ru/%D1%80%D0%B5%D0%BB%D0%B8%D0%B7-x265-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8-0-9/» оно по умолчанию остаётся 8bit.
И с какой стати он мне пишет «Forcing conversion to YV12», или YV12 может быть 10bit?
В LAV Video 10bit P010,P210,Y410,v210,v410.
Не то вы говорите.
Профиль Main10, кодирует исключительно только в 10-бит.
А вот профиль Main без приставки 10, кодирует именно в 8-бит.
*8bit видео пожатое в Main10, как я вас понял оно по умолчанию остаётся 8bit.*
8 бит пожатое в 10 становится 10-битным, также как и любое другое пожатое в 10.
——————————-
*И с какой стати он мне пишет «Forcing conversion to YV12″, или YV12 может быть 10bit?*
видимо у тебя на вход энкодеру подаётся видос цветового формата не YV12, а так как по умолчанию энкодер всё воспринимает как YV12 i420 — естественно он форсирует нужный формат для себя сам.
или конвертни видос в нужный формат или используй соответственные ключи энкода под свой формат:
—input-csp
Source color space: i420, i444, i422, nv12, nv16, auto-detected if Y4M. Default: i420
———————————
*В LAV Video 10bit P010,P210,Y410,v210,v410.*
да есть, но на выход ЛАВ всегда выдаёт 8бит YV12.
в опциях лава даже не отключаемый дитеринг-фильт стоит, при помощи которого он даунскейлит видос на 8 бит.
А ключ —recon-depth 8 позволит получать в 10bit кодеке 8bit?
по идее да, но смысл какой, бери сразу 8 в 8 гони 8-битным энкодером.
весь сок в 16-битном энкодере, что бы на выходе получить 10, 12, 16 битный видос.
Если будут использоваться технологии профиля Main то да, а если будут использоваться технологии Main10(Про которые я писал в первом посте) то должен быть прирост качества.А даже если будет профиль Main, то как минимум можно пользоваться одной версией кодека.
скорее всего при экоде 8 в 8 16-битным энкодером, автоматом включится и 8битная внутренняя обработка, и мы получим тотже энкод с темже результатом что и 8-битным энкодером, только времени на это будет потрачено раза в три больше.
для интереса попробуй по обжимать и сообщи результат…
————————————-
*как минимум можно пользоваться одной версией кодека.*
по аналогичному вопросу разраб уже давал ответ.
http://forum.doom9.org/showpost.php?p=1685174&postcount=1042
Хотел проверить как вы просили и не получилось из сборок Daemon404 1.2.45 и 1.2.81 на файлах *.y4m выкидывает.
Даже если включить принудительно ключом —recon-depth 8в профиле Main10, он один фиг будет кодировать в 10-бит.
10-бит на то и 10бит кодер, он исключительно будет кодировать только в 10-бит. Для кодирования 8-битного есть отдельный x265.
В общем не получится сделать как ты говоришь.
Да, но почему здесь: http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles в строке Bit depth для профиля Main10 стоит 8 to 10(от 8 до 10)?
возможно имеется в виду обязательное преобразование с 8 до 10 бит.
также как и до 12 и 16, в зависимости от выбранного профиля.
думаю м16п-хевк не умеет даунскейлить видос ниже 10 бит, так же как и авц-хай10…, хотя и принимает на вход 16бит.
полную строку ключей напиши, при которых выкидывает.
x265.exe —frame-threads 2 —ref 16 —bframes 16 —merange 48 —max-merge 5 —me 2 —subme 7 —rd 4 —aq-mode 2 —min-keyint 1 —keyint 25 —b-adapt 2 —rc-lookahead 40 —no-scenecut —early-skip —rdpenalty 2 —tu-intra-depth 2 —tu-inter-depth 2 —ssim —input-depth 8 —recon-depth 8 —output park —input park_joy_420_720p50.y4m
не хватает главных ключей:
—bitrate или —crf
Тьфу ты, я их забыл указать.
Я сюда скопировал строку из батника, а в него из последнего теста кодека,но пока переносил на основной компьютер этот параметр у меня вылетел из головы.
Извините завтра сделаю.
Сейчас добавил —bitrate 2048 тот же результат, а на —crf 34 выдал список параметров ошибок или предупреждений я не заметил.
Набрал сейчас —crf 34 тоже два раза выкинуло, может я прошлый раз при вводе —crf 34 чтото не верно набрал?
Немножко разобрался когда набираю заглавными(—CRF) пишет «unrecognized option» и выдаёт описание параметров, а когда строчными то выкидывает.
*выдал список параметров ошибок или предупреждений я не заметил.*
нужно знать чё он там ругаеца, поставь на паузу бтник или логи записывай, для прочитать.
————————-
у себя запускал —input-depth 8 —recon-depth 8 — ошибок небыло, но на выходе всё равно 10бит.
Я ставил, когда —CRF 34(заглавными) то пишет «Unrecognized option «—CRF»», а когда —crf 34(строчными) то после обсчёта первого кадра выкидывает, проверил вышеуказанную строку на двух компьютерах.
Глючит именно эта строка:
«—frame-threads 2 —ref 16 —bframes 16 —merange 48 —max-merge 5 —me 2 —subme 7 —rd 4 —aq-mode 2 —min-keyint 1 —keyint 25 —b-adapt 2 —rc-lookahead 40 —no-scenecut —early-skip —rdpenalty 2 —tu-intra-depth 2 —tu-inter-depth 2 —ssim —input-depth 8 —recon-depth 8 »
независимо от режима контроля битрейта(—crf или —bitrate)
На строке: «x265.exe —crf 34» всё заработало.
даже не знаю что подсказать…, так как не вижу всей картины происходящего.
обычно такие критические вылеты происходят по серьёзным причинам, как то энкодер не видит входящий видос, или 8битной версии скормиоли ключи от 16битной, и т.п.
думаю нужно начать с самого начального минимума, типа:
x265_16 —crf 34 «video.y4m» —output «video.hevc»
ну а дальше уже наращивать ключи и вычислять виновника…
Вот он не рабочий минимум: «x265.exe —crf 34 —rdpenalty 2 —rc-lookahead 40 —output Paris.raw —input paris_cif.y4m», на этой строке у меня выкидывает.
тогда убирай —rdpenalty, когда то с ним уже был баг вылета, потом это пофиксили, видимо терь опять заглючило.
Да , но это возможно другой баг так как —rdpenalty без —rc-lookahead работает.
проверил у себя связку пенальти2+локахед40 — всё пучком, вылетов нет.
А какая версия может они уже поправили?
Я тестировал на 1.2.45 и 1.2.81.
спецом у демона скачивал для проверки
x265-1.2.81-highbitdepth-icl14.0-64.7z
x265-1.2.81-highbitdepth-msvc2012-64.7z
обе сборки отработали без глюков.
ну и нашу местную x265_1.2+88_x64_16bpp.zip — аналогично.
Сейчас проверил 16bit с —rdpenalty 2 —rc-lookahead 40 не глючит, глючит 8bit просто на той длинной строке выкидывало на всех сборках по этому я тестировал на 8bit.
Только что запустил 16bit кодек с длинной строкой на другом компьютере
файл 288p обрабатывается, а 720p выкидывает, с короткой строкой аналогично.
может памяти маловато на борту?
На основном 12Gb, на этом 4Gb
Вот сейчас проверил съело 48Mb и выкинуло
странная какая то у тя аномалия.
забей тогда на какюю нить одну настройку, выкинь или пенальку или локахед да и всё., всё равно они такого особого смысла не несут.
попробуй через ависинт свой файл подать на экодер, врятли шото изменится, но малоли.
Да я с такими тяжелыми обычно не кодирую, просто попытался выловить баг если вы захотите сообщить разработчикам.
Подал через Avisynth 720p —crf 30 —rdpenalty 2 —rc-lookahead 40 выкинуло.
x265 жрет очень много памяти. Сколько памяти в системе?
Я же писал, на основном 12Gb и на этом 4Gb.
Выкидывает на обоих
Проверьте кто нибудь у себя —rdpenalty 2 —rc-lookahead 40 на 720p, а лучше на 1080p. Мне кажется это баг кодека.
проверил у себя:
Crowd_Run_1080p25.yuv + пенальти2 + локахед40 = вылет
Crowd_Run_1080p25.yuv + пенальти1 + локахед40 = порядок
——————————————————————-
Crowd_Run_2160p50.y4m + пенальти2 + локахед40 = вылет
Crowd_Run_2160p50.y4m + пенальти1 + локахед40 = порядок
——————————————————————
делаю вывод, что старый баг с пеналькой вернулся в зад.
Сайту форума не хватает
наконец то дождались, начиная с версии 1.2+305 доступен многопроходной энкод, но пока правда без упрощённого первого прохода.
Да, это хорошо. Но вот только увеличение качества между 1 и 2 проходами, сравнимо с разницей между 2 и 3 на x264, тоесть она есть, но на глаз её какбы и нет….
всё верно, это если настройки 1 прохода = настройкам 2 прохода.
аналогичное правило и у 264 с вторым и третьим проходом.
но на практике что в 264 любители третьего прохода всегда кодируют первый проход с ключём —slow-firstpass, дабы избавится от не нужного третьего прохода.
в случае 265 мы как бы имеем этот ключ по умолчанию, и для ускорения первого прохода нужно просто в ручную сбрасывать настройки для достижения нужного эффекта скорости/качества.
вот только в 265 что то сильно с файлом-статистики перестарались, полтора-часовой видос разрешения 1080 занимает в среднем аж гиг статистики…
Тогда объясните дураку, как в х265 правильно делать 2х проходное кодирование для видимого получения эффекта …
В х264 даже со slow-firstpass есть достаточно видимый эффект улучшения от 2 прохода, чего я не увидел в х265 =(
Использовал такой подход, меняя pass 1 > 2
—bitrate 6000 —input-res 1920×1080 —fps 29.970 —ref 8 —bframes 8 —merange 48 —me 2 —subme 7 —rd 4 —aq-mode 2 —aq-strength 0.8 —min-keyint 20 —b-adapt 2 —no-scenecut —early-skip —tu-intra-depth 2 —tu-inter-depth 2 —pass 1 —stats log265.log —input raw.yuv —output video.265
если это настройки первого=второго прохода, тогда их можно упростить в первом таким образом:
—bitrate 6000 —input-res 1920×1080 —fps 29.970 —ref 4 —bframes 8 —merange 24 —me 1 —subme 2 —rd 2 —aq-mode 2 —aq-strength 0.8 —min-keyint 20 —b-adapt 2 —no-scenecut —early-skip —tu-intra-depth 1 —tu-inter-depth 1 —pass 1 —stats log265.log —input raw.yuv —output NUL
получим прибавку в скорости на первом проходе
ну и вдогонку по настройкам в часности —aq-mode 2 и —aq-strength 0.8
ключ —aq-strength вроде как отменяет ключ —aq-mode 2 (авто) на ключ —aq-mode 1