|
<VIRUS>
Стаж: 16 лет 5 месяцев Сообщений: 7354
|
<VIRUS> ·
03-Авг-20 23:11
(4 года 4 месяца назад)
jensen123321 писал(а):
79859235Это неизбежно, не за горами замена 265 - му, (266), где прожорливость будет на порядок больше.
Ситуация закономерно идет к тому что все меньший прирост эффективности сжатия, будет даваться все большей ресурсоемкостью. Явная логарифмическая зависимость, и конец уже близок. Одна надежда на продвижение нового продукта, это талантливые маркетологи и выкручивание рук.
P.S. jensen123321 я без какого-либо упрека вам, просто по факту.
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
03-Авг-20 23:43
(спустя 31 мин., ред. 03-Авг-20 23:43)
<VIRUS> писал(а):
79864952все меньший прирост эффективности сжатия, будет даваться все большей ресурсоемкостью
Да нормальный такой прирост пока. Одинаковая картинка с разницей в 1-4 мегабита это вполне себе ок. Это если про рипы, а если про бд - 4к бд размером 53 гигабайта на фильм, при 1080 бд 48 гигабайт в среднем на фильм. А вот с 266 и ав1 вопрос уже, это да. В 266 обещают блоки 128 на 128, такое тредится ОЧЕНЬ плохо. У того же хевка 64 на 64 блоки дают прирост сжатия на 1-2 мегабита экономии битрейта супротив блоков 32 на 32, но отнимают 0.5 - 1 фпс от скорости.
|
|
Yan.Sarkiss
Стаж: 13 лет 4 месяца Сообщений: 336
|
Yan.Sarkiss ·
10-Авг-20 19:37
(спустя 6 дней, ред. 10-Авг-20 19:37)
jensen123321
я тут много страниц в этой ветке почитал.
И все же остался вопрос.
Слабые места h.265?
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
10-Авг-20 21:10
(спустя 1 час 33 мин.)
Yan.Sarkiss писал(а):
79896380Слабые места h.265?
Нужно курить офф сайт с описанием ключей и крутить настройки под конкретный исходник. Просто бахнуть дефолт и получить хороший результат не выйдет.
|
|
Yan.Sarkiss
Стаж: 13 лет 4 месяца Сообщений: 336
|
Yan.Sarkiss ·
10-Авг-20 21:27
(спустя 16 мин., ред. 10-Авг-20 21:27)
jensen123321 писал(а):
79896772Просто бахнуть дефолт и получить хороший результат не выйдет.
Да, так и думал. Получается h.264 в этом плане полегче будет? И результата приближенному к исходнику легче добиться с h.264?
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
10-Авг-20 22:40
(спустя 1 час 13 мин., ред. 10-Авг-20 22:40)
Yan.Sarkiss писал(а):
79896846И результата приближенному к исходнику легче добиться с h.264?
Да, но ценой повышенного относительно 265 битрейта. Баш на баш выходит. В 265 очень плохие дефолтные настройки, те же пресеты в 264 хоть и были дерьмом, но показывали нормальный результат, а в 265 они просто убивают картинку.
|
|
Yan.Sarkiss
Стаж: 13 лет 4 месяца Сообщений: 336
|
Yan.Sarkiss ·
10-Авг-20 23:56
(спустя 1 час 15 мин.)
jensen123321 писал(а):
79897059Да, но ценой повышенного относительно 265 битрейта. Баш на баш выходит. В 265 очень плохие дефолтные настройки, те же пресеты в 264 хоть и были дерьмом, но показывали нормальный результат, а в 265 они просто убивают картинку.
Спасибо, подтвердили мои сомнения, что h.264 лучше h.265.
Я вообще за Hi10p всегда топил, и если вставал выбор между ремуксом и ним, брал последний. Разниицы почти не замечаю.
С хевком такие номера не всегда прокатывают. Вроде картинка норм, но что-то не то.
Еще раз спасибо большое!
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
11-Авг-20 10:01
(спустя 10 часов)
Yan.Sarkiss
Просто берите рипы от нормальных команд, а не всяких "judas" и иже с ними. Даже моззи научился рипать в 265 нормально, если закрыть глаза на фильтрацию. Можно смотреть нас - беатрис, vcb, кавайка равс.
|
|
Yan.Sarkiss
Стаж: 13 лет 4 месяца Сообщений: 336
|
Yan.Sarkiss ·
11-Авг-20 11:15
(спустя 1 час 13 мин., ред. 11-Авг-20 11:15)
jensen123321
Цитата:
Можно смотреть нас - беатрис, кавайка равс
только эти и смотрю хоть и у пследнего всегда hevc 10bit.
|
|
johnowenemmet
Стаж: 14 лет 10 месяцев Сообщений: 124
|
johnowenemmet ·
13-Авг-20 07:22
(спустя 1 день 20 часов)
бинарники x265.exe с какого компилятора лучше брать? VS 2015, VS 2019 или GCC 10.1??
процессор интел 9700К, сейчас используется VS 2019
|
|
brother225
Стаж: 16 лет 1 месяц Сообщений: 130
|
brother225 ·
13-Авг-20 09:38
(спустя 2 часа 16 мин.)
johnowenemmet
GCC 10.1
на https://forum.doom9.org провели тест.Разница настолько небольшая,что можно не заморачиваться.
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
13-Авг-20 12:00
(спустя 2 часа 21 мин.)
johnowenemmet
Для авх2 лучше гсс
|
|
Слышь ты
Стаж: 7 лет 2 месяца Сообщений: 404
|
Слышь ты ·
09-Сен-20 00:48
(спустя 26 дней)
H265 хорошо ведёт себя на малых разрешениях. Но маленькие разрешения не выгодны, и с ними борются. А при 1080 и выше — конечно 100500 отмазок и тестов о том, что у H265 овчинка выделки не стоит, и постоянные спичи об этом, "ая-яй, плохой и не нужен H265".
|
|
Koo1
Стаж: 15 лет 7 месяцев Сообщений: 1139
|
Koo1 ·
09-Сен-20 12:58
(спустя 12 часов)
Слышь ты писал(а):
80034004Но маленькие разрешения не выгодны, и с ними борются.
Что?
|
|
Tracker35
Стаж: 16 лет 1 месяц Сообщений: 830
|
Tracker35 ·
09-Сен-20 15:21
(спустя 2 часа 22 мин., ред. 09-Сен-20 15:21)
Слышь ты
Как раз таки наоборот, за счет 64 макроблоков h265 все более лучше показывает себя на больших форматах нежели h264 с 32 макроблоками.
Но, есть достаточно спорный момент: когда использование 64ых макроблоков переваливает за определенный % относительно 32ых, то не лучше-бы использовать downscale на меньший формат и без использования 64ых макроблоков, а растяжку под 4к+ поручить уже upscale алгоритмам*, нежели алгоритмам расчета/поиска/сжатия кодека.
То-же самое касается и 32ых относительно 16ых маркоблоков - зачем кодировать видео по качеству как ~480р в 1080р, когда можно закодировать сразу в 480р
*p.s. нейро-алгоритмы ресайза (например как DLSS в играх) встроенные уже напрямую в плеер, смогут на лету превратить детализорованный 1080р в детализорованный 4к.
Тогда как заблюренный кодеком 4к, так и останется заблюренным 4к (хотя есть метод через downscale->upscale с поиском подходящего наименьшего формата для последующей обработки нейронки, но то требует доп. мощностей и подключением "метрик качества" которые увы далеко не совершенны)
|
|
Tracker35
Стаж: 16 лет 1 месяц Сообщений: 830
|
Tracker35 ·
25-Сен-20 06:14
(спустя 15 дней, ред. 25-Сен-20 06:14)
Описание кодера Taobao S265 (они там еще какойто декодер делают, что на 140% быстрее ffmpeg)
https://www.livevideostack.cn/news/taobao-hevc-h265-cdn-rtc/
Если пытаться вникнуть в слова через ломанный язык переводчика, то по сути они описывают альтернативные подходы к сжатию H265 потока , нежели большинство других кодеров опирающихся либо на оригинал, либо x264-x265, но с последующей возможностью декода всеми h265-совместимыми. Сравнивая его с x265 в разных методах, приводя разницу в %, что в конечном итоге суммируется в до 50% преимущество (над x265) и в качестве, и в скорости.
Создается впечатление некого xvid-divx среди остальных ASP кодеров, который(е), в своё время, пошли чуть дальше изначальных стандартов на енкодер.
|
|
Cortney
Стаж: 12 лет 2 месяца Сообщений: 1142
|
Cortney ·
28-Ноя-20 23:09
(спустя 2 месяца 3 дня, ред. 28-Ноя-20 23:26)
вот
MI
Общее
Уникальный идентификатор : 264928311588173991860246960308692429091 (0xC74F563B2B812488F2A4F2652F8BA923)
Полное имя : R:Обитель зла. Коллекция1. Обитель зла. 2002. 1080p. HEVC. 10 bit.mkv
Формат : Matroska
Версия формата : Version 4 / Version 2
Размер файла : 5,95 Гбайт
Продолжительность : 1 ч. 40 м.
Общий поток : 8470 Кбит/сек
Дата кодирования : UTC 2020-10-26 13:27:38
Программа кодирования : mkvmerge v28.2.0 ('The Awakening') 64-bit
Библиотека кодирования : libebml v1.3.6 + libmatroska v1.4.9
Обложка : Yes
Attachments : cover.jpg Видео
Идентификатор : 1
Формат : HEVC
Формат/Информация : High Efficiency Video Coding
Профиль формата : Main 10@L5.1@High
Идентификатор кодека : V_MPEGH/ISO/HEVC
Продолжительность : 1 ч. 40 м.
Битрейт : 7188 Кбит/сек
Ширина : 1920 пикселей
Высота : 1040 пикселей
Соотношение сторон : 1,85:1
Режим частоты кадров : Постоянный
Частота кадров : 23,976 (24000/1001) кадра/сек
Цветовое пространство : YUV
Субдискретизация насыщенности : 4:2:0
Битовая глубина : 10 бит
Бит/(Пиксели*Кадры) : 0.150
Размер потока : 5,05 Гбайт (85%)
Библиотека кодирования : x265 2.8+74-fd517ae68f93:[Windows][GCC 7.3.0][64 bit] 10bit
Настройки программы : cpuid=1049583 / frame-threads=5 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=3 / input-csp=1 / input-res=1920x1040 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=5 / allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=6 / scenecut=40 / radl=0 / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=3 / subme=7 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei
Язык : English
Default : Да
Forced : Нет Аудио #1
Идентификатор : 2
Формат : AC-3
Формат/Информация : Audio Coding 3
Идентификатор кодека : A_AC3
Продолжительность : 1 ч. 40 м.
Вид битрейта : Постоянный
Битрейт : 640 Кбит/сек
Каналы : 6 каналов
Расположение каналов : Front: L C R, Side: L R, LFE
Частота : 48,0 КГц
Частота кадров : 31,250 кадров/сек (1536 SPF)
Битовая глубина : 16 бит
Метод сжатия : С потерями
Размер потока : 460 Мбайт (8%)
Язык : Russian
ServiceKind/Strin : Complete Main
Default : Да
Forced : Нет Аудио #2
Идентификатор : 3
Формат : AC-3
Формат/Информация : Audio Coding 3
Идентификатор кодека : A_AC3
Продолжительность : 1 ч. 40 м.
Вид битрейта : Постоянный
Битрейт : 640 Кбит/сек
Каналы : 6 каналов
Расположение каналов : Front: L C R, Side: L R, LFE
Частота : 48,0 КГц
Частота кадров : 31,250 кадров/сек (1536 SPF)
Битовая глубина : 16 бит
Метод сжатия : С потерями
Размер потока : 460 Мбайт (8%)
Заголовок : Eng
Язык : English
ServiceKind/Strin : Complete Main
Default : Нет
Forced : Нет Текст #1
Идентификатор : 4
Формат : UTF-8
Идентификатор кодека : S_TEXT/UTF8
Идентификатор кодека/Информация : UTF-8 Plain Text
Продолжительность : 1 ч. 32 м.
Битрейт : 52 бит/сек
ElementCount : 695
Размер потока : 35,8 Кбайт (0%)
Заголовок : Rus
Язык : Russian
Default : Нет
Forced : Нет Текст #2
Идентификатор : 5
Формат : UTF-8
Идентификатор кодека : S_TEXT/UTF8
Идентификатор кодека/Информация : UTF-8 Plain Text
Продолжительность : 1 ч. 28 м.
Битрейт : 32 бит/сек
ElementCount : 666
Размер потока : 20,9 Кбайт (0%)
Заголовок : Eng
Язык : English
Default : Нет
Forced : Нет Меню
00:00:00.000 : :(01)00:00:00:000
00:08:22.585 : :(02)00:08:22:585
00:11:00.409 : :(03)00:11:00:409
00:19:09.940 : :(04)00:19:09:940
00:23:49.010 : :(05)00:23:49:010
00:29:22.469 : :(06)00:29:22:469
00:37:51.227 : :(07)00:37:51:227
00:41:14.555 : :(08)00:41:14:555
00:47:11.829 : :(09)00:47:11:829
00:52:16.591 : :(10)00:52:16:591
01:00:47.977 : :(11)01:00:47:977
01:08:35.694 : :(12)01:08:35:694
01:12:05.321 : :(13)01:12:05:321
01:18:33.667 : :(14)01:18:33:667
01:24:22.348 : :(15)01:24:22:348
01:30:16.160 : :(16)01:30:16:160
как понять хорошие это настройки для hevc или нет? для x264 понимаю, а для x265 есть какая-нибудь расшифровка ключей, - что там за что отвечает и на что влияет?
|
|
Koo1
Стаж: 15 лет 7 месяцев Сообщений: 1139
|
Koo1 ·
28-Ноя-20 23:19
(спустя 10 мин.)
Cortney
Ничего нет, кроме английской доки (что тоже намекает на нужность этого кодека, по моему).
|
|
Cortney
Стаж: 12 лет 2 месяца Сообщений: 1142
|
Cortney ·
28-Ноя-20 23:32
(спустя 12 мин.)
Koo1
ну, то есть, никак не сориентироваться перед скачиванием - хороший это релиз или плохой. только скачать и там уже решать.
удобно, ничего не скажешь.
ясн. спасибо.
|
|
-Drakon-
Стаж: 16 лет 9 месяцев Сообщений: 337
|
-Drakon- ·
01-Дек-20 14:54
(спустя 2 дня 15 часов)
Cortney, почему же? Есть ключи общие с х264 (ref, bframes, b-adapt, subme, deblock), по ним можно смотреть, плюс некоторые параметры можно почерпнуть из темы https://rutr.life/forum/viewtopic.php?t=4295233, т.е. не должны быть: no-weightb, no-b-intra, open-gop, me ниже 2, subme ниже 3, ctu ниже 32, tu-intra-depth ниже 2, tu-inter-depth ниже 2, bframes ниже 8, rc отличный от 2 pass, crf.
Но я бы немного подкорректировал его: tu-inter-depth= 4, tu-intra-depth= 4, no-sao, rd=6, subme=7, no-cutree.
|
|
Cortney
Стаж: 12 лет 2 месяца Сообщений: 1142
|
Cortney ·
01-Дек-20 15:23
(спустя 28 мин.)
-Drakon- писал(а):
80495038т.е. не должны быть: no-weightb, no-b-intra, open-gop, me ниже 2, subme ниже 3, ctu ниже 32, tu-intra-depth ниже 2, tu-inter-depth ниже 2, bframes ниже 8, rc отличный от 2 pass, crf.
Но я бы немного подкорректировал его: tu-inter-depth= 4, tu-intra-depth= 4, no-sao, rd=6, subme=7, no-cutree.
спасибо. из приведенного мною MI видно, что рип плохой. я в этом убедился когда скачал и сравнил.
а вот , кстати, Бит/(Пиксели*Кадры) имеет значение или нет?
и еще. если попадется лог кодирования, то в каких пределах должны быть кванты: как у 264 или есть нюансы? или это тут вообще роли не играет?
|
|
-Drakon-
Стаж: 16 лет 9 месяцев Сообщений: 337
|
-Drakon- ·
01-Дек-20 15:47
(спустя 24 мин., ред. 01-Дек-20 15:47)
Cortney, я не рипую в х265, просто немного смотрел и спрашивал когда пошла мода на такие рипы, сейчас же с повальным увлечением фильтрацией я от рипов в х265 отказался совсем.
Бит на пиксель разумеется имеет значение, такое же как и для х264, если же про его конкретное значение, то тут нужно смотреть лог кодирования и на кванты, т.е. аналогично с х264. Касательно же значений квантов, то встречал информацию, может и в этой же теме, что для b-frames кванты не должны выходить за 22, но тут я уверен не на все 100.
|
|
Cortney
Стаж: 12 лет 2 месяца Сообщений: 1142
|
Cortney ·
01-Дек-20 15:53
(спустя 6 мин.)
-Drakon-
что ж, я понял. спасибо за инфо
|
|
-Drakon-
Стаж: 16 лет 9 месяцев Сообщений: 337
|
-Drakon- ·
01-Дек-20 16:07
(спустя 13 мин.)
|
|
Koo1
Стаж: 15 лет 7 месяцев Сообщений: 1139
|
Koo1 ·
01-Дек-20 16:21
(спустя 13 мин.)
-Drakon- писал(а):
80495300что для b-frames кванты не должны выходить за 22
Вранье, если это не статичная картинка.
|
|
-Drakon-
Стаж: 16 лет 9 месяцев Сообщений: 337
|
-Drakon- ·
01-Дек-20 18:24
(спустя 2 часа 3 мин.)
Koo1, может и так, но если вы владеете другой информацией, то поделитесь ею, думаю интересующиеся будут вам за это благодарны.
|
|
Koo1
Стаж: 15 лет 7 месяцев Сообщений: 1139
|
Koo1 ·
01-Дек-20 19:03
(спустя 38 мин.)
-Drakon-
Зависит от фпс и динамики, универсальных правильных значений лога нет.
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
03-Дек-20 15:43
(спустя 1 день 20 часов, ред. 03-Дек-20 15:43)
Koo1 писал(а):
80480970английской доки
А нужно что-то еще, лол?
Если интересует более подробные описания и тд работы каждого ключа велком в тему 265 на думме. Там даже разрабы х265 отвечают порой. Естественно на английском.
Пока вы ждёте русских гайдов, народ уже все изучил и использует.
Алсо, там подвезли вроде как аппаратное ускорение кодирования для 265.
скрытый текст
They claim it's 20% more efficient than open source according to MSU but the real interesting thing is that they seem to have a hybrid GPU/CPU HEVC encoder, that runs on NVIDIA's RTX video cards, it seems to use software based bit rate and quality algorithms with GPU powered encoding, in other words not the NVENC encoder but a combination of CUDA and their software encoder, which they say is 2.5x as fast as their software encoder.
|
|
varnav
Стаж: 18 лет 4 месяца Сообщений: 30
|
varnav ·
05-Дек-20 04:29
(спустя 1 день 12 часов, ред. 05-Дек-20 04:29)
Джентльмены. Экспериментирую с кодированием в HEVC через NVENC на GPU от nVidia.
На мобильной GTX2060 удаётся добиться скорости кодирования FullHD стабильно 174 кадров/сек и хорошего качества на таких настройках:
Код:
ffmpeg -xerror -hwaccel auto -vsync 0 -i .\input.mp4 -rc-lookahead 15 -map_metadata 0 -movflags use_metadata_tags -preset p6 -spatial-aq 1 -temporal_aq 1 -cq 26 -vcodec hevc_nvenc -acodec copy output.mp4
По данным агенства ОБС карты начиная от 20 серии стали уже сносно кодировать и не портят качество.
Есть желающие узнать подробности? У меня терабитный канал, можем покрутить то-сё.
|
|
Tracker35
Стаж: 16 лет 1 месяц Сообщений: 830
|
Tracker35 ·
05-Дек-20 05:28
(спустя 59 мин., ред. 05-Дек-20 05:28)
varnav
В hevc он кодирует неплохо начиная с Turing ядер, когда сделали B-кадры, качество ~ x264-medium
А чтобы выжать максимум, нужно юзать этот енкодер https://github.com/rigaya/NVEnc/releases
Цитата:
узнать подробности?
А какие подробности, акромя того, что все hardware енкодеры предназначены для стримов или быстрого создания lossless ...
Разве, что вам нужно быстро пересжать ~15 ГБ фильм в 5 раз, для просмотра на телефоне, где рассматривать пиксели нужно сразу под двумя лупами, чтобы увидеть просадку по качеству.
|
|
|