|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
25-Янв-21 23:38
(3 года 10 месяцев назад, ред. 25-Янв-21 23:38)
Tracker35 писал(а):
80801251p.s. Надеюсь LCEVC не обрастет патентами, и его можно будет применять в симбиозе с x264 в открытую, в будущем... и плюс еще 10 лет для 264'го ...
Будто у 264 проблема в скорости, кек. Да он на самом древнем железе весьма шустрый. У него другие проблемы - он устарел и не декодируется железом (10 бит). Вот если LCEVC решит проблему аппаратного декодирования 10 битного 264 - это будет здорово.
|
|
|
|
Koo1
Стаж: 15 лет 7 месяцев Сообщений: 1142
|
Koo1 ·
26-Янв-21 10:10
(спустя 10 часов)
Почему нет аппаратного ускорения 264 10 бит?
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
26-Янв-21 11:08
(спустя 58 мин., ред. 26-Янв-21 11:08)
Koo1
Его поддержку дропнули, так как появился hevc. Под 265 сделали целую базу, как это обычно бывает - куча устройств с поддержкой, 10 битный стандарт 4к видео на uhdbd и тд. Все потому, что об этом думали еще при разработке стандарта кодека. А 10 бит в 264 - это доп режим, появившейся в 2011 году, тогда как сам стандарт - 8 бит изначально, под что и заточено куча устройств воспроизведения. Намного проще поменять парк устройств под новый кодек, чем менять его под нововведения старого, особенно, если эти нововведения используются только любителями в интернете.
|
|
|
|
volta_john
Стаж: 14 лет 6 месяцев Сообщений: 780
|
volta_john ·
26-Янв-21 13:24
(спустя 2 часа 16 мин.)
jensen123321
При кодировании с тяжелыми настройками на ЦП в x264 без фильтрации в ависинте/вапорсинте я бы не отказался от кратного ускорения даже на своих рязане и зеоне. Про древнее железо просто смешно, на нём такое кодирование идёт со скоростью ~ 5-10 к/с.
Аппаратную поддержку h264 10-бит никто никогда не дропал. Она изначально планировалась только для про-сектора электроники и там вполне себе жила, живёт и будет жить. Использование же 10-бит в секторе бытовой электроники признали тогда нецелесообразным и преждевременным - соответственно, никто и не собирался немного позже внедрять её туда.
jensen123321 писал(а):
У него другие проблемы - он устарел
И в чём/как эта проблема выражается? 
|
|
|
|
greyback777
Стаж: 4 года 1 месяц Сообщений: 37
|
greyback777 ·
26-Янв-21 14:41
(спустя 1 час 17 мин.)
я в H265 не сильно шарю . сгодиится такое или продолжим поиск
скрытый текст
Writing library : x265 1.8+1-5dcc9d3a928c400b:[Windows][GCC 5.2.0][64 bit] 8bit
Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=3 / tu-inter-depth=3 / me=2 / subme=4 / merange=57 / no-rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=40 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=0 / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=2.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=1.00 / rdoq-level=0 / psy-rdoq=0.00 / signhide / deblock=-1:-1 / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=19.3 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
двухчасовой фильм с ас3 5.1 640 + ас3 2.0 192 ( всего две озвучки ) влез на 7 гигов в 1080
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
26-Янв-21 15:59
(спустя 1 час 18 мин., ред. 26-Янв-21 15:59)
volta_john писал(а):
808212405-10 к/с
Это очень большая скорость. Вы точно не путаете 5-10 фпс в секунду у кодировщика с 0.5 фпс в секунду у старых пк? Ну и вообще мы говорим о чистой скорости 264. 10 бит 264 без фильтрации на 775 сокете (квад 6600) выдавал 1.4 фпс. Потому я и упомянул старое железо. Естественно, ни про какие пентиумы речи не идёт. 265 же для нормальной скорости кодирования требует уже что-то из 2015 хотя бы.
volta_john писал(а):
80821240И в чём/как эта проблема выражается?
Официально разработка 264 закончена. 10 бит не поддерживается аппаратно. При наличии аппаратной поддержки 10 бит у его переемника - 265. Этого мало? Понятно, что 8 бит еще проживёт очень долго, как и сам 264, но когда на смену одному кодеку приходит другой, являющейся его улучшенной версией - это называется "устаревание".
|
|
|
|
Koo1
Стаж: 15 лет 7 месяцев Сообщений: 1142
|
Koo1 ·
26-Янв-21 17:11
(спустя 1 час 11 мин.)
На Ютубе, не знаю, наверно, уже 50% более-менее популярных видях в av1
|
|
|
|
volta_john
Стаж: 14 лет 6 месяцев Сообщений: 780
|
volta_john ·
26-Янв-21 17:20
(спустя 8 мин.)
jensen123321
Читайте внимательней.
volta_john писал(а):
При кодировании с тяжелыми настройками на ЦП в x264 без фильтрации в ависинте/вапорсинте
То есть, разумеется, я писал о скорости чистого x264, и под тяжелыми настройками имел ввиду именно настройки, а не 10-бит. 6600? Окей, вот его типичные результаты в x264 бенче: https://forums.overclockers.ru/viewtopic.php?p=5019358&sid=d7347ebf98e1fc20fd...ef21921#p5019358
Примерно 15 к/с на втором проходе двупроходки бенча. Под тяжелыми настройками (пресеты slower/veryslow) те самые 5 к/с он и выдавал.
jensen123321 писал(а):
Официально разработка 264 закончена. 10 бит не поддерживается аппаратно. При наличии аппаратной поддержки 10 бит у его переемника - 265. Этого мало? Понятно, что 8 бит еще проживёт очень долго, как и сам 264, но когда на смену одному кодеку приходит другой, являющейся его улучшенной версией - это называется "устаревание".
Понятно. Как и ожидалось, проблем у него нет.
|
|
|
|
pashka_chem
Стаж: 14 лет 11 месяцев Сообщений: 133
|
pashka_chem ·
06-Фев-21 13:44
(спустя 10 дней, ред. 06-Фев-21 13:44)
-ololoev- писал(а):
79859211xfiles
Скорость кодирования в 264 зависит от настроек. Можно подобрать настройки, при которых 264 будет медленнее, но даст все равно худший результат, чем 265й при менее суровой конфигурации. Я так понимаю, jensen123321 об этом хотел сказать.
Какая чушь 
jensen123321 писал(а):
79896772
Yan.Sarkiss писал(а):
79896380Слабые места h.265?
Нужно курить офф сайт с описанием ключей и крутить настройки под конкретный исходник. Просто бахнуть дефолт и получить хороший результат не выйдет.
В принципе можно "бахнуть" и с одинаковыми настройками, но при это придётся поколдовать с фильтрами хотя бы Avisynth
-Drakon- писал(а):
80495300Cortney, я не рипую в х265, просто немного смотрел и спрашивал когда пошла мода на такие рипы, сейчас же с повальным увлечением фильтрацией я от рипов в х265 отказался совсем.
Бит на пиксель разумеется имеет значение, такое же как и для х264, если же про его конкретное значение, то тут нужно смотреть лог кодирования и на кванты, т.е. аналогично с х264. Касательно же значений квантов, то встречал информацию, может и в этой же теме, что для b-frames кванты не должны выходить за 22, но тут я уверен не на все 100.
Согласен с многими заявлениями, но только не бит/пиксель. Это же средняя температура по больнице
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
08-Фев-21 01:36
(спустя 1 день 11 часов)
pashka_chem писал(а):
80884952Согласен с многими заявлениями, но только не бит/пиксель. Это же средняя температура по больнице
Это даже не метрика кодеков, это метрика контейнера.
|
|
|
|
-Drakon-
Стаж: 16 лет 9 месяцев Сообщений: 337
|
-Drakon- ·
10-Фев-21 00:31
(спустя 1 день 22 часа, ред. 10-Фев-21 00:31)
pashka_chem, jensen123321 уважаемые риперы х265, человек просто спросил, как я помню, на что можно посмотреть в медиаинфо перед скачиванием для составления приблизительного мнения о качестве.
И да бит на пиксель показывает лишь то, сколько информации тратится на 1 пиксель изображения в секунду и чем он выше, говоря по простому, тем лучше, как и в случае битрейта. Смотреть на эти показатели можно только в рипах с одинаковым разрешением и закодированных одним кодеком. Если я неправильно выразился, то прошу прошения у всех, кого мог ввести в заблуждение.
А вот не является ли он излишним/ раздутым - другой вопрос, на который даст ответ только лог кодирования со значениями квантов. Но он есть далеко не во всех рипах. И совсем уж, чтоб наверняка, то покадровое сравнение.
Так же я ему посоветовал некоторые значения в настройках кодирования, как общих для х264, так и специфичных для х265: no-weightb, no-b-intra, open-gop, me не ниже 2, subme не ниже 7, ctu не ниже 32, tu-intra-depth не ниже 4, tu-inter-depth не ниже 4, bframes не ниже 8, rc отличный от 2 pass, crf, no-sao, rd не ниже 6, no-cutree.
Если по ним у вас есть дополнения, то будьте любезны напишите их.
Тем, кто хочет составить для себя список значений и параметров для отличия нормального рипа от халтуры без скачивания обоих "конкурсантов", это бы сильно пригодилось.
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
12-Фев-21 01:20
(спустя 2 дня, ред. 12-Фев-21 01:20)
-Drakon- писал(а):
80906121Так же я ему посоветовал некоторые значения в настройках кодирования, как общих для х264, так и специфичных для х265: no-weightb, no-b-intra, open-gop, me не ниже 2, subme не ниже 7, ctu не ниже 32, tu-intra-depth не ниже 4, tu-inter-depth не ниже 4, bframes не ниже 8, rc отличный от 2 pass, crf, no-sao, rd не ниже 6, no-cutree.
Если по ним у вас есть дополнения, то будьте любезны напишите их.
Это как раз чушь.
no-weightb - лучше включать (будет написано weightb), no-b-intra - не замечал явного влияния как на качество, так и на производительность (upd - протестировал, значение по умолчанию (включено) лучше не менять, иначе возникает потеря деталей (но это на моем исходнике, на других может быть по другому), tu-intra-depth не ниже 4, tu-inter-depth не ниже 4 - оптимальное значение при aq 3 - 2, при aq 4 - 2 или 3 (4 дает артефакты на большинстве исходников (помогает лишь на некоторых, ту как повезет), 3 помогает на шумных исходниках, но может давать артефакты на гладких, а значение 2 довольно нейтральное, bframes не ниже 8 - для 4к избыточно, там и 4 и 6 норм, да и на 1080 значения выше 6 могут вызвать артефакты на аппаратном декодере, no-cutree - дерево у 265 это вам не дерево у 264, тут оно умнее и очень выручает на шумных исходниках, но если оно включено на гладком сорце - это в 99% означает ненужное занижение битрейта и как следствие - потерю деталей.
|
|
|
|
pashka_chem
Стаж: 14 лет 11 месяцев Сообщений: 133
|
pashka_chem ·
12-Фев-21 18:07
(спустя 16 часов)
-Drakon- писал(а):
Так же я ему посоветовал некоторые значения в настройках кодирования, как общих для х264, так и специфичных для х265: no-weightb, no-b-intra, open-gop, me не ниже 2, subme не ниже 7, ctu не ниже 32, tu-intra-depth не ниже 4, tu-inter-depth не ниже 4, bframes не ниже 8, rc отличный от 2 pass, crf, no-sao, rd не ниже 6, no-cutree.
Если по ним у вас есть дополнения, то будьте любезны напишите их.
попробую добавить.
open-gop - скорее рассчитан был на совместимость, но с сегодняшним прогрессом скорее неактуален. (ИМХО)
по subme не всё так однозначно, по qpel итерациям например 4 выигрывает у 5 и 6. но 7 однозначно перекрывает всю совокупность.
tu-inter-depth - да пусть хоть равен 1, это настолько мизерное влияние на сжатие, но так тормозящее процесс, что я использую его скорее по инерции.
cutree- cоглашусь штука спорная, но на киноматериале съедает детализацию, как бы размывая мелкодисперсный шум. При этом естественно значительно снижает размер. Есть ещё один немаловажный факт, что и заставляет меня его отключать -при оном включённом часто наблюдается "зависание" блоков. (кусок шума в виде квадрата на протяжении сцены, или наоборот лысый блок)
по aq моё решение неизменно - для сохранения деталей только aq1, размер возрастёт, но если правильно подобрать силу в связке с no-cutree, то можно подровнять результат. aq4 и hevc-aq меня ни разу не устроили по результату на тестах.
sao-это получение низкобитретных результатов без заточки на детализацию (убивает детали, но самостоятельно делает что-то наподобие дебандинга и устраняет некоторые артефакты по краям объектов). Вполне неплохо для проходных сериалов.
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
12-Фев-21 19:53
(спустя 1 час 46 мин., ред. 12-Фев-21 19:53)
pashka_chem писал(а):
80920251open-gop - скорее рассчитан был на совместимость, но с сегодняшним прогрессом скорее неактуален. (ИМХО)
В стандарте бд 4к он есть, так что я думаю, лучше включать длч рипов, некая гарантия читаемости аппаратными декодерами.
pashka_chem писал(а):
80920251зависание
Не из-за дерева оно, это следствие нехватки битрейта (причиной может являться дерево) и если одновременно занижен деблок, то это гарантия вот таких вот зависаний. Если у вашего исходника при любом раскладе появляются такие зависшие блоки, вам необходимо сделать следующее --ctu 32 --max-tu-size 16, повысить значение деблока, повысить значение psy rdog и возможно покрутить qcomp немножко для повышения битрейта на 1-2 мегабита, этого, вместе с блоками на 32, а не 64 должно быть достаточно для избавления от таких артефактов. Мне редко встречаются исходники, где лезет вот такое, но они есть. Работает это так - кодек видит плоские текстуры и для лучшего сжатия применяет к ним блок 64х64, подчиняясь адаптивному кванту от cutree и в момент резкой смены сцены (фейд в темноту или наоборот) может не успеть изменить анализ. Потому в таких переходах из обычного кадра через плавное затенение в "черноту" эти огромные блоки 64х64 становятся видны, ну или при общем недостатке битрейта эти блоки будут видны по всему видео.
Касательно дерева - есои ваш исходник представляет собой скан с пленки с сильным зерном, дерево лучше включить. Оно замечательно находит весь шум (динамику) и применяет к нему более высокий квантазер (сильнее сжатие), перебрасывая сэкономленный битрейт на статичные сцены. Визуально это выглядит намного лучше, чем попытки срезать средний битрейт путем общих настроек сжатия ( crf и bitrate).
pashka_chem писал(а):
80920251sao-это получение низкобитретных результатов без заточки на детализацию
Наоборот - это способ убрать артефакты сжатия при низких (очень) битрейтах. Бесконечное дробление и размытие блоков и тд снижает детализацию, но делает изображение лучше визуально (гладкая текстура вместо артефакта сжатия на ней (искажение границ или зависший блок)).
|
|
|
|
pashka_chem
Стаж: 14 лет 11 месяцев Сообщений: 133
|
pashka_chem ·
12-Фев-21 20:23
(спустя 30 мин., ред. 12-Фев-21 20:23)
jensen123321 писал(а):
Наоборот - это способ убрать артефакты сжатия при низких (очень) битрейтах. Бесконечное дробление и размытие блоков и тд снижает детализацию, но делает изображение лучше визуально (гладкая текстура вместо артефакта сжатия на ней (искажение границ или зависший блок)).
И где здесь наоборот? Я тоже самое сказал, но с другой стороны))
jensen123321 писал(а):
Не из-за дерева оно, это следствие нехватки битрейта (причиной может являться дерево) и если одновременно занижен деблок, то это гарантия вот таких вот зависаний. Если у вашего исходника при любом раскладе появляются такие зависшие блоки, вам необходимо сделать следующее --ctu 32 --max-tu-size 16, повысить значение деблока, повысить значение psy rdog и возможно покрутить qcomp немножко для повышения битрейта на 1-2 мегабита, этого, вместе с блоками на 32, а не 64 должно быть достаточно для избавления от таких артефактов.
Так дерево и даёт эту нехватку битрейта и прочие косяки.
можно выкрутить qcomp ?, не проще ли тогда кодировать не crf, а просто "q=18". в 1080p вообще ставить анализ блоков 64*64 нецелесообразно. Скорость ниже, результата меньше, чем ноль.
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
12-Фев-21 21:22
(спустя 58 мин., ред. 12-Фев-21 21:22)
pashka_chem писал(а):
80921066И где здесь наоборот? Я тоже самое сказал, но с другой стороны))
У тебя читается "сао режет битрейт".
pashka_chem писал(а):
80921066можно выкрутить qcomp ?, не проще ли тогда кодировать не crf, а просто "q=18"
Дык к примеру изменение со стандартных 0.60 до 0.72 дает прирост 1.5 мегабита к среднему битрейту, что в большинстве случаев и требуется для компенсации занижения битрейта всякими деревьями и тд.
pashka_chem писал(а):
80921066в 1080p вообще ставить анализ блоков 64*64 нецелесообразно. Скорость ниже, результата меньше, чем ноль.
В аниме очень большой профит за счет "аниме", лол. Много плоских областей, где можно эти 64 на 64 использовать и экономить битрейт. А в кино мб и не катит, соглашусь.
|
|
|
|
Tracker35
Стаж: 16 лет 1 месяц Сообщений: 830
|
Tracker35 ·
13-Фев-21 14:34
(спустя 17 часов, ред. 13-Фев-21 14:34)
jensen123321
все-же нужно создавать отдельную тему, "HEVC(H.265) для «аниме»"
т.к. весьма специфичный кодек по контенту, с весьма разнящимся подходом к сжатию, что отчасти создает недопонимание между людьми использующими его ...
то, что для аниме будет хорошо и экономия, для остального контента приводит к обратному эффекту. Хотя если брать низкие и сверхнизкие битрейты, то некоторые плюшки активно использующиеся в «аниме-сжатии» - будут весьма кстати.
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
13-Фев-21 21:30
(спустя 6 часов)
Tracker35
Мб, но все это опять же в тему о настройках 265, просто тип контента поменялся.
|
|
|
|
johnowenemmet
Стаж: 14 лет 10 месяцев Сообщений: 125
|
johnowenemmet ·
26-Мар-21 16:28
(спустя 1 месяц 12 дней)
Заметили ощутимый ап по скорости в 3.5+1 ?
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
20-Авг-21 00:14
(спустя 4 месяца 24 дня)
Ну что, тему можно закрывать и создавать новую, VVC(H.266) и x266? 
|
|
|
|
Koo1
Стаж: 15 лет 7 месяцев Сообщений: 1142
|
Koo1 ·
20-Авг-21 14:14
(спустя 13 часов)
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
20-Авг-21 18:06
(спустя 3 часа)
Koo1 писал(а):
81863908и AV1
Да кому он нужен...
|
|
|
|
Koo1
Стаж: 15 лет 7 месяцев Сообщений: 1142
|
Koo1 ·
20-Авг-21 19:02
(спустя 55 мин., ред. 20-Авг-21 19:02)
jensen123321
Гуглу, как минимум, на Ютубе в браузере у меня где-то 60% видео VP9, 30 AV1 и только 10 264, при том компу почти 10 лет и аппаратного ускорения 265 и VP9 нет
|
|
|
|
jеnsen
Стаж: 14 лет 7 месяцев Сообщений: 2961
|
jеnsen ·
20-Авг-21 19:41
(спустя 38 мин., ред. 20-Авг-21 19:41)
Koo1
Дык именно в том и дело, удел av1 - веб, а мы же говорим про универсальные кодеки (264/65/66). То, что использует / будет использовать каждый второй при создании / перекодировании видео.
|
|
|
|
dima0byte
Стаж: 17 лет 1 месяц Сообщений: 15
|
dima0byte ·
05-Ноя-21 19:40
(спустя 2 месяца 15 дней)
Я не понимаю зачем в 2021 году продолжают выкладывать xvid да еще и 480p, извращение какое-то, никому уже это не нужно.
Делайте минимум 720p и используйте hevc/x265 (10 bit) + opus. В 1гб можно зажать шикарную картинку.
Уже dvbt2 тюнеры с usb дыркой за 700₽ на полке любого занюханного магаза могут x265 сожрать, тем более 720p.
|
|
|
|
johnowenemmet
Стаж: 14 лет 10 месяцев Сообщений: 125
|
johnowenemmet ·
05-Ноя-21 21:52
(спустя 2 часа 11 мин.)
dima0byte писал(а):
82239461используйте hevc/x265 (10 bit) + opus. В 1гб можно зажать шикарную картинку.
Так это свершившийся факт или предположение?
|
|
|
|
Мазизов
Стаж: 7 лет 6 месяцев Сообщений: 1132
|
Мазизов ·
05-Ноя-21 21:57
(спустя 4 мин.)
johnowenemmet писал(а):
82240239это свершившийся факт или предположение?
Это бред.
|
|
|
|
dima0byte
Стаж: 17 лет 1 месяц Сообщений: 15
|
dima0byte ·
06-Ноя-21 20:27
(спустя 22 часа)
Мазизов писал(а):
82240289
johnowenemmet писал(а):
82240239это свершившийся факт или предположение?
Это бред.
Ничего не бред
Вот ровно 1гб видео стрим x265 1080p 10bit 16:9
+ аас, но если бы был opus 160kb/s то еще всего 200 мб
Код:
General
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.70 GiB
Duration : 2 h 43 min
Overall bit rate : 1 488 kb/s
Movie name : Blade Runner 2049 2017 Open Matte (1080p x265 q22 FS96 Joy)[UTR]
Encoded date : UTC 2019-08-23 23:14:25
Writing application : mkvmerge v32.0.0 ('Astral Progressions') 64-bit
Writing library : libebml v1.3.7 + libmatroska v1.5.0
Attachments : poster.eng.jpg
Writing frontend : StaxRip v2.0.2.0, a JoyBell Encode
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main [email protected]@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 43 min
Bit rate : 862 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.017
Stream size : 1 007 MiB (58%)
Writing library : x265 3.0_Au+24-4217e691387c:[Windows][GCC 9.1.1][64 bit] 10bit
Encoding settings : rc=crf / crf=21.5000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / qpmax=69 / qpmin=0 / no-lossless / no-cu-lossless / hevc-aq / no-aq-motion / aq-mode=3 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / ipratio=1.40 / pbratio=1.30 / psy-rd=2.50 / psy-rdoq=0.80 / deblock=-2:-2 / ref=4 / limit-refs=3 / limit-modes / bframes=8 / b-adapt=2 / bframe-bias=20 / b-pyramid / no-b-intra / weightp / no-weightb / keyint=250 / min-keyint=23 / rc-lookahead=80 / gop-lookahead=0 / scenecut=40 / scenecut-bias=0.05 / ctu=64 / min-cu-size=8 / me=3 / subme=5 / merange=57 / rd=4 / no-rd-refine / ssim-rd / dynamic-rd=0.00 / rdoq-level=2 / rdpenalty=0 / cutree / sao / no-limit-sao / no-sao-non-deblock / rect / no-amp / open-gop / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / qg-size=32 / wpp / no-pmode / no-pme / no-psnr / ssim / no-tskip / constrained-intra / strong-intra-smoothing / max-merge=5 / nr-intra=0 / nr-inter=0 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=235139 / level-idc=0 / high-tier=1cpuid=1111039 / frame-threads=3 / numa-pools=12 / log-level=2 / uhd-bd=0 / lookahead-slices=4 / radl=0 / no-splice / no-intra-refresh / signhide / temporal-mvp / no-analyze-src-pics / early-skip / rskip / no-fast-intra / no-tskip-fast / no-splitrd-skip / zone-count=0 / no-strict-cbr / no-rc-grain / no-const-vbv / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=1 / 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 / no-opt-cu-delta-qp / 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 / refine-ctu-distortion=0 / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-svt / qp-adaptation-range=1.00
Default : Yes
Forced : No
Color range : Limited
Matrix coefficients : BT.709
Audio #1
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 2 h 43 min
Bit rate : 362 kb/s
Channel(s) : 8 channels
Channel positions : Front: L C R, Side: 4, LFE
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 spf)
Compression mode : Lossy
Delay relative to video : 20 ms
Stream size : 424 MiB (24%)
Language : English
Default : No
Forced : No
|
|
|
|
johnowenemmet
Стаж: 14 лет 10 месяцев Сообщений: 125
|
johnowenemmet ·
06-Ноя-21 20:30
(спустя 3 мин.)
Боже, куда катится этот мир?
|
|
|
|
Messa-fan
Стаж: 14 лет 7 месяцев Сообщений: 1286
|
Messa-fan ·
06-Ноя-21 21:02
(спустя 31 мин.)
dima0byte писал(а):
82246250
Мазизов писал(а):
82240289
johnowenemmet писал(а):
82240239это свершившийся факт или предположение?
Это бред.
Ничего не бред
Вот ровно 1гб видео стрим x265 1080p 10bit 16:9
+ аас, но если бы был opus 160kb/s то еще всего 200 мб
скрытый текст
Код:
General
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.70 GiB
Duration : 2 h 43 min
Overall bit rate : 1 488 kb/s
Movie name : Blade Runner 2049 2017 Open Matte (1080p x265 q22 FS96 Joy)[UTR]
Encoded date : UTC 2019-08-23 23:14:25
Writing application : mkvmerge v32.0.0 ('Astral Progressions') 64-bit
Writing library : libebml v1.3.7 + libmatroska v1.5.0
Attachments : poster.eng.jpg
Writing frontend : StaxRip v2.0.2.0, a JoyBell Encode
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main [email protected]@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 43 min
Bit rate : 862 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.017
Stream size : 1 007 MiB (58%)
Writing library : x265 3.0_Au+24-4217e691387c:[Windows][GCC 9.1.1][64 bit] 10bit
Encoding settings : rc=crf / crf=21.5000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / qpmax=69 / qpmin=0 / no-lossless / no-cu-lossless / hevc-aq / no-aq-motion / aq-mode=3 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / ipratio=1.40 / pbratio=1.30 / psy-rd=2.50 / psy-rdoq=0.80 / deblock=-2:-2 / ref=4 / limit-refs=3 / limit-modes / bframes=8 / b-adapt=2 / bframe-bias=20 / b-pyramid / no-b-intra / weightp / no-weightb / keyint=250 / min-keyint=23 / rc-lookahead=80 / gop-lookahead=0 / scenecut=40 / scenecut-bias=0.05 / ctu=64 / min-cu-size=8 / me=3 / subme=5 / merange=57 / rd=4 / no-rd-refine / ssim-rd / dynamic-rd=0.00 / rdoq-level=2 / rdpenalty=0 / cutree / sao / no-limit-sao / no-sao-non-deblock / rect / no-amp / open-gop / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / qg-size=32 / wpp / no-pmode / no-pme / no-psnr / ssim / no-tskip / constrained-intra / strong-intra-smoothing / max-merge=5 / nr-intra=0 / nr-inter=0 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=235139 / level-idc=0 / high-tier=1cpuid=1111039 / frame-threads=3 / numa-pools=12 / log-level=2 / uhd-bd=0 / lookahead-slices=4 / radl=0 / no-splice / no-intra-refresh / signhide / temporal-mvp / no-analyze-src-pics / early-skip / rskip / no-fast-intra / no-tskip-fast / no-splitrd-skip / zone-count=0 / no-strict-cbr / no-rc-grain / no-const-vbv / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=1 / 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 / no-opt-cu-delta-qp / 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 / refine-ctu-distortion=0 / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-svt / qp-adaptation-range=1.00
Default : Yes
Forced : No
Color range : Limited
Matrix coefficients : BT.709
Audio #1
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 2 h 43 min
Bit rate : 362 kb/s
Channel(s) : 8 channels
Channel positions : Front: L C R, Side: 4, LFE
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 spf)
Compression mode : Lossy
Delay relative to video : 20 ms
Stream size : 424 MiB (24%)
Language : English
Default : No
Forced : No
Уровень вашего любимого 480p XviD по качеству
|
|
|
|
