|
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
16-Апр-14 21:00
(10 лет 7 месяцев назад)
Bill Ein писал(а):
63626739А как к --b-adapt 0 отнесутся смартфоны и планшеты при онлайн-просмотре?
Не владею информацией, но думаю, что положительно, т.к. это одна из самых простых схем построения группы.
Bill Ein писал(а):
63626739Как именно должен выглядеть по вашему двухпроходный
Не владею информацией, т.к. использую только однопроходку в crf, чего и другим желаю. Спор, что лучше - пустая трата времени, Я в такие игры не играю.
|
|
|
|
Bill Ein
Стаж: 15 лет 4 месяца Сообщений: 272
|
Bill Ein ·
17-Апр-14 09:45
(спустя 12 часов, ред. 18-Апр-14 16:13)
Tim68 писал(а):
Не владею информацией, т.к. использую только однопроходку в crf, чего и другим желаю. Спор, что лучше - пустая трата времени, Я в такие игры не играю.
Для средних и высоких битрейтов при определённых настройках разница будет минимальна, но на низких битрейтах, а точнее при откровенной нехватке оного преимущество за двухпроходкой, что, впрочем, может быть вполне субъективно.
Но проблема в том, что 480х270 и 500 кбпс взяты потому, что на определённом сайте есть ограничение на вес файла в 4 (максимум 5) МБ/мин с ограничением на горизонталь 480 пикс. и вертикаль - 360. Причём видео должно адекватно воспроизводиться онлайн без тормозов.
Вот тут и требуется всё мастерство, чтобы придерживаясь данных рамок сохранить адекватное качество картинки, тем более анимешной с большой концентрацией динамики.
Tim68, а ведь всё-таки да - картинка при keyint=fps и b-adapt=0 гораздо лучше, правда пришлось кое-что ещё поменять, чтобы стало ещё лучше:
было:
Код:
--bitrate 504 --ref 2 --bframes 2 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct auto --partitions all --no-mbtree --deblock 0:0 --no-psy --no-fast-pskip --b-pyramid none --ratetol 100
стало:
Код:
--bitrate 504 --ref 2 --bframes 2 --trellis 2 --b-adapt 0 --me tesa --subme 11 --direct auto --partitions all --no-mbtree --deblock 0:0 --no-psy --aq-mode 2 --no-dct-decimate --no-fast-pskip --keyint 30 --ratetol 100
И опять же при ref/bframes=2/2 артефактов всё-таки меньше чем при 1/1 и 3/3, так что хоть и большое вам спасибо за keyint и b-adapt, но в плане подбора ref и bframes я остался при своём мнении.
P.S. И всё-таки улучшение качества вышло весьма неоднозначным, а именно пропажа блендинга в одних местах обернулась смазанностью линий обводки в динамике и появлению блендинга в других местах. Тем не менее на мой взгляд всё-таки стало лучше, но всё же такие методы были хороши лишь в данной ситуации, а вот для средних и высоких битрейтов и разрешений я бы так делать никому не посоветовал.
|
|
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
18-Апр-14 19:41
(спустя 1 день 9 часов)
|
|
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
18-Апр-14 21:36
(спустя 1 час 55 мин., ред. 19-Апр-14 09:08)
Bill Ein писал(а):
63631200при ref/bframes=2/2 артефактов всё-таки меньше чем при 1/1 и 3/3
При всем при том (keyint, b-adapt) использование bframes=3 требует b-pyramid в значении strict, т.к. только в этом случае можно будет получить самую оптимальную схему ссылок внутри подгруппы кадров.
Tim68 писал(а):
49593722Существующее ограничение для x264 в использовании только одного В-кадра как ссылочного в каждой подгруппе (miniGOР-е) приводит к ситуации, когда в DPB могут быть загружены ссылочные P и В-кадры ближайших предыдущих подгрупп группы. Насколько ценны их макроблоки (MB) для предсказываемого кадра? Не секрет, что наилучшие МВ, максимально подходящие для использования содержат только наиболее близкие кадры, более удаленные по причине значительных изменений в сцене менее значимы и чем дальше, тем менее значимы.
Например, две хронологических последовательности кадров с максимальным количеством разрешенных последовательных B кадров в подгруппе. Первая с bframe=3, вторая с bframe=16,
где P и B-ссылочные кадры, а b-предсказываемый кадр:
1.)..PbBbPbBbPbBb..,
2.)..PbbbbbbbbBbbbbbbbPbbb..
Если в первом случае (bframe=3) даже при использовании максимально разрешенного количества В кадров ссылочные P и B кадры, расположены близко к предсказываемому кадру, то во втором случае все не так радужно, предсказывать, основываясь на МВ столь удаленных кадров задача не из легких и требует больших радиусов и тяжелых алгоритмов поиска движения. Понятным становиться и то, что при вышеуказанных ограничениях увеличение количества ссылочных (референсных) кадров приведет лишь к заполнению DPB кадрами с все менее значимыми для предсказания MB и не более, особенно при использовании длинных последовательностей B кадров, что будет снижать эффективность работы буфера до абсолютно нерациональной.
Bill Ein писал(а):
63631200Тем не менее на мой взгляд всё-таки стало лучше, но всё же такие методы были хороши лишь в данной ситуации, а вот для средних и высоких битрейтов и разрешений я бы так делать никому не посоветовал.
Длинные группы, со всей их сложной обвязкой как раз и даны для низких битрейтов, просто высокие потоки невелируют их ущербность.
Tim68 писал(а):
49685460При стремлении GOP к 1-це получаем структуру IIIII... , т.е. беспотерьное межкадровое(редакция) сжатие, при стремлении к бесконечности - полная потеря информации, по какому бы алгоритму мы не соединили две крайние точки (1 и бесконечность), то по мере удаления от 1-цы будет расти потерьность
Да, короткие группы еще любят --open-gop.
|
|
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
18-Апр-14 21:52
(спустя 15 мин., ред. 18-Апр-14 21:52)
огромнейший битрейт для мультика, где минимум деталей и движухи, да ещё и в 3д, плоский мультик конвертнули в 3д мультик, какой 3д в плоском мультфильме где почти все объекты выглядят 2д как никрути
https://rutr.life/forum/viewtopic.php?t=4680292
|
|
|
|
Bill Ein
Стаж: 15 лет 4 месяца Сообщений: 272
|
Bill Ein ·
19-Апр-14 12:48
(спустя 14 часов, ред. 19-Апр-14 16:26)
DotaSeal писал(а):
63649128огромнейший битрейт для мультика, где минимум деталей и движухи, да ещё и в 3д, плоский мультик конвертнули в 3д мультик, какой 3д в плоском мультфильме где почти все объекты выглядят 2д как никрути
https://rutr.life/forum/viewtopic.php?t=4680292
Первая ошибка: считать анимацию ущербной и лёгкой в плане кодирования. А вот ***! Не размазать и не рассыпать линии обводки тоже не шибко-то легко; как и сохранить адекватные градиенты при отсутствии оригинального зерна киноплёнки и соответствующей текстуры; а также сложно не засрать картинку артефактами, которые очень хорошо заметны именно на анимации. Всех этих проблем при кодировании фильмов многие просто не знают и не ощущают, поэтому просто тупо крутят ручку битрейта, расставляя все прочие настройки от балды, лишь бы кодировалось побыстрее и весило поменьше.
Вторая ошибка: минимум деталей и движухи у Диснея? Вы вообще в курсе, что все диснеевские полнометражные мульты имеют анимацию на всех 24фпс, а не как в современных мульт- и аниме-сериалах - на 1 из двух-шести? Так что движухи там вполне хватает.
Третья ошибка: если я правильно понял, то это вообще не рип, а БД-ремукс в ISO-шнике.
Tim68 писал(а):
При всем при том (keyint, b-adapt) использование bframes=3 требует b-pyramid в значении strict, т.к. только в этом случае можно будет получить самую оптимальную схему ссылок внутри подгруппы кадров.
Но как же b-adapt=0? Ведь он же обнуляет bpyramid...
Tim68 писал(а):
Длинные группы, со всей их сложной обвязкой как раз и даны для низких битрейтов, просто высокие потоки невелируют их ущербность.
Эм... почему тогда никто не сокращает группы для BD-рипов?
|
|
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
19-Апр-14 20:45
(спустя 7 часов, ред. 19-Апр-14 20:45)
Bill Ein писал(а):
63654681Но как же b-adapt=0? Ведь он же обнуляет bpyramid...
Откуда такая информация? Например из отчета MediaInfo по медиафайлу 59.97fps:
Код:
Настройки программы:
cabac=1 / ref=6 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / psy_rd=0.95:0.10 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-3 / threads=3 / lookahead_threads=1 / sliced_threads=0 / slices=1 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=0 / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=1 / keyint=60 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=0 / crf=20.0 / qcomp=0.60 / qpmin=16 / qpmax=32 / qpstep=4 / vbv_maxrate=14000 / vbv_bufsize=14500 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.10 / pb_ratio=1.10 / aq=1:1.00
Bill Ein писал(а):
63654681Эм... почему тогда никто не сокращает группы для BD-рипов?
Вопрос не ко Мне.
|
|
|
|
Bill Ein
Стаж: 15 лет 4 месяца Сообщений: 272
|
Bill Ein ·
20-Апр-14 08:50
(спустя 12 часов)
Tim68 писал(а):
Откуда такая информация?
Да я затупил просто.
Попробовал strict - изменения для двухпроходки с bitrate=500 и bitrate 400 в плане качества и веса ну просто очень мизерные и опять же по качеству весьма спорно как-то вышло: в паре мест заметны улучшения, но в другом месте стало хуже. При подъёме битрейта до 536 разница в качестве между b-pyramid=1 и b-pyramid=2 и вовсе исчезла, но с b-pyramid=1 вес вышел чуть-чуть меньше чем при b-pyramid=2, но в тоже самое время для bitrate 400 вышло наоборот.
|
|
|
|
SurvivorXXX
Стаж: 13 лет 3 месяца Сообщений: 238
|
SurvivorXXX ·
20-Апр-14 10:13
(спустя 1 час 22 мин.)
прошу объяснить начинающему кодеру в каких случаях деблокинг выставляют 1:-1:-1; 1:-2:-2 и 1:0:0 (насколько я в курсе, это самая плохая настройка?). ну и 1:-3:-3. есть какие-то критерии/рекомендации?
|
|
|
|
alfsuind
Стаж: 14 лет 8 месяцев Сообщений: 880
|
alfsuind ·
20-Апр-14 10:34
(спустя 20 мин.)
SurvivorXXX
Чем ниже значения - тем больше сохраняется деталей, но и больше "квадратов". Чем выше - тем все сглаженнее. В пресетах x264 рекомендуют понижать для фильмов (например -1/-1), повышать для "плоской" анимации (например 1/1), 0/0 - тоже неплохое значение.
До улучшений x264 2008 года x264 в целом давал слишком "сглаженную", "пластмассовую" картинку, и поэтому в качественных высокобитрейтных рипах стали делать деблок -3/-3, чтобы сохранить все детали.
Но сейчас это дань традиции, т.к. улучшения 2008 года также уменьшают количество деблока в нужных местах. Плюс надо помнить, что чем выше битрейт, тем деблока меньше при любых его настройках. *
Если делать "идеальный" рип, то все равно разницы между -1/-1 и -3/-3 практически не видно.
http://forum.doom9.org/showpost.php?p=1540772&postcount=6
* сила деблока автоматически уменьшается в зонах с низкими квантами. В высокобитрейтных рипах кванты обычно низкие, а AQ и psy-rd их дополнительно понижают в нужных местах, да так, что даже вспомнили и отменили qpmin=10.
|
|
|
|
Bill Ein
Стаж: 15 лет 4 месяца Сообщений: 272
|
Bill Ein ·
20-Апр-14 13:41
(спустя 3 часа, ред. 20-Апр-14 13:41)
alfsuind, я бы сказал так: чем ниже значения - тем выше детализация, но и больше артефактов там, где не хватило битрейта/CRF. Psy-rd вносит шум, т.е. повышает кол-во деталей на блок, следовательно чтобы адекватно сохранить этот шум необходимо понизить deblock. Но в тоже самое время из-за psy-rd (даже не снижая deblock) на самые простые сцены потребуется битрейта на порядок больше, а значит и на сложных его потребуется ещё больше, следовательно нехватка битрейта/CRF выльется в весьма серьёзные артефакты, которые могут быть видны лишь на самых сложных сценах, а понижая deblock мы их лишь ещё больше усилим.
Т.е. всё зависит от сложности самого видео: для какого-то можно впердолить и низкий битрейт c deblock -3:-3, а для какого-то высокий c deblock всего лишь 0:0. Причём может быть весьма не очевидно что в действительности будет лучше: повысить битрейт или понизить deblock.
Поэтому лично я рекомендую начинать все эксперименты со значения deblock 0:0, особенно при кодировании в 10бит.
P.S. И я категорически не советую повышать deblock при использовании psy-rd, а для "плоской" анимации тем более.
|
|
|
|
SurvivorXXX
Стаж: 13 лет 3 месяца Сообщений: 238
|
SurvivorXXX ·
20-Апр-14 15:00
(спустя 1 час 18 мин.)
alfsuind
Bill Ein
спасибо за ответы. я в общем-то старался использовать пресеты meGUI для кодирования фильмов. в одном из них для HD выставлено значение -1:-1. думаю, это не худший вариант.
|
|
|
|
Bill Ein
Стаж: 15 лет 4 месяца Сообщений: 272
|
Bill Ein ·
20-Апр-14 15:28
(спустя 28 мин., ред. 27-Апр-14 10:49)
|
|
|
|
Bill Ein
Стаж: 15 лет 4 месяца Сообщений: 272
|
Bill Ein ·
24-Апр-14 12:38
(спустя 3 дня, ред. 26-Апр-14 17:30)
И всё-таки опять хочу вернуться к вопросу о блендинге.
Если в 8бит без psy-rd мне удалось от него избавиться полностью (да-да, на этот раз всё-таки полностью, а не как раньше) с CRF17 и озвученными на прошлой странице настройками кодирования, то с psy-rd более-менее удачно лишь с CRF16, но всё же некоторые очертания в паре мест остались. А вот в 10бит с psy-rd всё очень и очень плохо, даже понижение до CRF12 не даёт тех же результатов, что были в 8бит с CRF16... На одном из сайтов подсказали, что бленд проступает по хроме, а значит deadzone не поможет в принципе, ибо эта настройка исключительно для люмы. Может у кого-то есть предположения и идеи на этот счёт?
Единственное решение для 10бит, которое я нашёл, это b-adapt=1, но основная проблема - слишком большой вес конечного файла, причём при повышении CRF с 15 до 16 блендинг снова всплывает (зато хорошо, что он снова стал зависеть от CRF).
|
|
|
|
Игросглаживатель
Стаж: 12 лет 1 месяц Сообщений: 321
|
Игросглаживатель ·
26-Апр-14 18:06
(спустя 2 дня 5 часов, ред. 26-Апр-14 21:52)
Здравствуйте. Подскажите, пожалуйста, какие настройки лучше подойдут для шумного исходника, чтобы лучше сжать с меньшими потерями. В самом изображении много темноты, мало содержания но из-за шума битрейт зашкаливает при crf=18 - 22 Мб/с, по предыдущему опыту на подобном чистом изображении с этими настройками без заметных потерь должно было быть около 3 Мб/с.
Encoding settings
cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.20 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Исходник
Видео crf=18 (можно посмотреть шум)
Лог
PLATFORM
------------------------------
OS Code: Microsoft Windows NT 6.1.7601 Service Pack 1
OS Name: Windows 7 Ultimate Service Pack 1 (x64)
Framework: 2.0.50727.5446 (v4.0)
AviSynth: AviSynth 2.60, build:Sep 28 2013 [15:09:12]
CPU Info: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz (~3309), 4 core(s)
RAM Total: 8175Mb
Language: RUS (1251, ",")
SystemDrive: C:
XviD4PSP
------------------------------
Version: 5.10.330.0
Created: 19.03.2013 07:34:12
AppPath: C:\Program Files (x86)\XviD4PSP 5
TempPath: f:\Temp
FILES
------------------------------
S.avi >
S.mkv
TASK
------------------------------
Format: MKV
Duration: 00:00:16:333 (490)
VideoDecoder: AVISource
Resolution: 1920x1080
Aspect: 1.7778
VCodecPreset: Custom
VEncodingMode: Quality
VideoCodec: FRAPS > x264 (x64)
VideoBitrate: 299618 > Q18.0
Framerate: 30.000
SourceType: PROGRESSIVE
FieldOrder: UNKNOWN
AEncodingPreset: AAC-LC ABR 192k
AudioCodec: PCM > AAC
AudioBitrate: 1536 > 192
Samplerate: 48000
Channels: 2
SCRIPT
------------------------------
Import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\AudioFunctions.avs")
Import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\VideoFunctions.avs")
SetMemoryMax(1024)
SetMTMode(3, 3)
AVISource("F:\S.avi")
SetMTMode(2)
ConvertToYV12()
###[FILTERING]###
###[FILTERING]###
AUDIO ENCODING
------------------------------
Encoding audio to: f:\Temp\0216.m4a
AAC 192kbps 2ch 16bit 48000khz
neroAacEnc.exe: -ignorelength -br 192000 -lc -if - -of "f:\Temp\0216.m4a"
VIDEO ENCODING
------------------------------
Encoding video to: f:\Temp\0216.264
x264 Q18.0 1920x1080 30.000fps (490 frames)
avs4x264.exe: -L x264_64.exe --crf 18.0 --preset medium --level 4.1 --ref 4 --deblock -1:-1 --b-adapt 2 --trellis 0 --no-dct-decimate --psy-rd 1.00:0.20 --threads 4 --subme 9 --me umh --rc-lookahead 50 --sar 1:1 --output "f:\Temp\0216.264" "f:\Temp\0216.avs"
raw [info]: 1920x1080p 1:1 @ 30/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 4.1
x264 [info]: frame I:2 Avg QP:19.99 size:181789
x264 [info]: frame P:156 Avg QP:20.92 size:121550
x264 [info]: frame B:332 Avg QP:21.61 size: 88475
x264 [info]: consecutive B-frames: 1.4% 4.1% 61.8% 32.7%
x264 [info]: mb I I16..4: 1.7% 80.6% 17.6%
x264 [info]: mb P I16..4: 0.3% 25.2% 3.5% P16..4: 26.8% 30.7% 12.3% 0.0% 0.0% skip: 1.2%
x264 [info]: mb B I16..4: 0.1% 9.3% 0.8% B16..8: 31.8% 28.7% 8.7% direct: 8.5% skip:12.2% L0:47.5% L1:45.1% BI: 7.4%
x264 [info]: 8x8 transform intra:88.5% inter:51.6%
x264 [info]: coded y,uvDC,uvAC intra: 98.1% 95.2% 65.2% inter: 71.6% 61.3% 12.9%
x264 [info]: i16 v,h,dc,p: 35% 8% 2% 54%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 4% 2% 12% 18% 16% 14% 13% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 4% 1% 10% 15% 18% 14% 14% 13%
x264 [info]: i8c dc,h,v,p: 51% 17% 17% 15%
x264 [info]: Weighted P-Frames: Y:15.4% UV:9.0%
x264 [info]: ref P L0: 38.0% 12.6% 24.6% 14.8% 9.2% 0.9%
x264 [info]: ref B L0: 62.3% 28.7% 9.0%
x264 [info]: ref B L1: 83.7% 16.3%
x264 [info]: kb/s:23852.59
x264 [total]: encoded 490 frames, 4.42 fps, 23852.59 kb/s
MUXING
------------------------------
Video file: f:\Temp\0216.264
Audio file: f:\Temp\0216.m4a
Muxing to: F:\Walkthrough\S.mkv
mkvmerge.exe: -o "F:\Walkthrough\S.mkv" --engage no_cue_duration --engage no_cue_relative_position --default-duration 0:30.000fps -d 0 -A -S "f:\Temp\0216.264" -a 0 -D -S --no-chapters "f:\Temp\0216.m4a" --output-charset UTF-8
TIME
------------------------------
Общее время кодирования: 1 min 54 sec
Файл получился на: 46.83 mb
|
|
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
26-Апр-14 19:01
(спустя 55 мин., ред. 26-Апр-14 19:01)
я бы выкрутил деблок на 3\3, может даже на 6\6 и выключить psy. Если не поможет можно пройтись фильтрами которые подавляют шум
но из-за фильтров будет резкое падение в скорости кодирования
что это вообще такое? кадр из игры чтоле? в игре самой же не должно быть шума
|
|
|
|
Игросглаживатель
Стаж: 12 лет 1 месяц Сообщений: 321
|
Игросглаживатель ·
26-Апр-14 19:36
(спустя 34 мин.)
игра. шум это эффект в самой игре, иногда используется в ужастиках. шум надо оставить.
|
|
|
|
Lenchik
Стаж: 18 лет 4 месяца Сообщений: 854
|
Lenchik ·
26-Апр-14 19:54
(спустя 18 мин., ред. 26-Апр-14 20:07)
пробовать вам много разных вариантов надо:
3-4 разных режима aq + их настройки
включенный и отключенный mbtree
-- tune grain возможно
А все комбинации вышеназванного — это довольно много попыток кодирования на тестовом образце и бешенное затраченное время на сравнения скриншотов.
Может быть вам просто двухпроходно закодировать в 3 Мб/с?
Можете ещё архивы этой и темы по обработке и пересжатию полистать в пределе до 3 лет назад. Кто-то приходил и спрашивал как тёмные сцены без артефактов кодировать — там были рекомендации и сравнения скринов.
https://rutr.life/forum/viewtopic.php?p=53247539#53247539 — вот отсюда начинается одно из обсуждений с советами
и вот из заметок от опытных кодеров, которая уже точно канула в Лету по причине чисток старых тем:
Цитата:
crf + aq 3-1.1 очень хорошо собирает темный фон (да и не только темный), но подмыливает передний план
Если замыл в пределах разумного, то при просмотре его не будет видно практически, тогда как дыры по фону видны сразу и дают лишнее мельтешение на экране
Я обычно выбираю делать фон, терпеть не могу эту "хдтвшную" блочность
А вот сейчас делаю "The Thing 2011", там весь видеоряд темный, а aq-strength 1.1 не годится, сразу мажет не в меру(
|
|
|
|
Evgeny Crow
Стаж: 17 лет 3 месяца Сообщений: 623
|
Evgeny Crow ·
26-Апр-14 20:05
(спустя 11 мин., ред. 26-Апр-14 22:50)
Игросглаживатель писал(а):
63732836игра. шум это эффект в самой игре, иногда используется в ужастиках. шум надо оставить.
Так вам визуальное качество надо, или шум оставить? Потому что с таким разрешением, скорее всего, получится только что-то одно. Или снижайте разрешение до умеренного (раза в 2). Иначе вместо шума будет размазня / артефакты.
На хорошо сохраненный шум надо как раз CRF 18-19 минимум и я бы даже ещё некоторые настройки покрутил (активно кушающие битрейт).
А вы знаете толк в извращениях. Проводить много_тестов кодека с таким исходником - это только время переводить.
Лучше освойте самые азы фильтрации/реставрации таких исходников, визуальное качество вырастёт значительно заметнее (хоть на 500 килобит, хоть на 2500), чем если перебирать 1000 настроек икса.
|
|
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
26-Апр-14 20:49
(спустя 43 мин., ред. 26-Апр-14 20:49)
Игросглаживатель
чем ты захватываешь видео из игры? я бы рекомендовал фрапс, ибо изначально безпотерь он записывает видео
да и скриншот у тебя в jpg, а он сжимает изображение, дай картинку в png
Bill Ein
не надо давать такие примеры изображений , противно на это смотреть же.
|
|
|
|
Игросглаживатель
Стаж: 12 лет 1 месяц Сообщений: 321
|
Игросглаживатель ·
26-Апр-14 21:03
(спустя 14 мин., ред. 26-Апр-14 21:48)
Цитата:
Так вам визуальное качество надо, или шум оставить?
нужно уменьшить размер без заметной потери изначального изображения, возможно мои настройки которыми я пользовался на чистых исходниках для этого не подходят или это в принципе невозможно. похожие трудности были и на чистых со множеством шевелящихся объектов типа травы тоже значительно увеличивался битрейт.
Цитата:
чем ты захватываешь видео из игры? да и скриншот у тебя в jpg
fraps, jpg качество=95 разницы с исходным bmp не вижу.
Цитата:
это довольно много попыток кодирования
уже много потрачено на получение исходников, существуют в единственном экземпляре и удалятся после кодирования
Цитата:
Может быть вам просто двухпроходно закодировать в 3 Мб/с?
привёл для примера как шум повлиял на битрейт
|
|
|
|
busoti
Стаж: 13 лет 5 месяцев Сообщений: 2839
|
busoti ·
27-Апр-14 03:24
(спустя 6 часов, ред. 27-Апр-14 03:24)
Игросглаживатель
Без шумодава не получится оставить шум, исходное разрешение и сжать с меньшим битрейтом.
И всёравно надо искать компромисс.
|
|
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
27-Апр-14 09:42
(спустя 6 часов)
Игросглаживатель
ты же всё равно будешь на ютуб заливать, а он раздавит твоё видео под свои жалкие мизерные настройки
|
|
|
|
Bill Ein
Стаж: 15 лет 4 месяца Сообщений: 272
|
Bill Ein ·
27-Апр-14 11:41
(спустя 1 час 58 мин., ред. 27-Апр-14 11:41)
Evgeny Crow писал(а):
А вы знаете толк в извращениях. Проводить много_тестов кодека с таким исходником - это только время переводить.
Лучше освойте самые азы фильтрации/реставрации таких исходников, визуальное качество вырастёт значительно заметнее (хоть на 500 килобит, хоть на 2500), чем если перебирать 1000 настроек икса.
Отнюдь, сударь, ибо уже всё что можно перебрал и выяснил ряд вещей о которых ранее не догадывался. Блендинг от кодирования позволил мне узнать:
1) что для конкретного видео, CRF и битности есть лишь 1 оптимальный вариант ref/bframes напрямую зависящий от deblock и b-adapt;
2) что для конкретного видео, CRF и битности есть лишь 1 оптимальный вариант psy-rd который можно подобрать и который совершенно не зависит от ref/bframes, deblock и b-adapt;
3) что для конкретного видео, CRF и битности есть лишь 1 оптимальный вариант deblock
4) что для конкретного видео и битности c определённого момента понижать CRF становится бессмысленно без переключения b-adapt c 2 на 1, равно как и с определённого момента повышать не меняя b-adapt c 2 на 0
А что дадут ваши азы фильтрации исходника, если полученное качество не удаётся закодировать? К тому же я знаю эти азы. В моей практике был пример, когда херовые серые градиенты удавалось восстановить только сильным шумом, а вот закодить этот шум стало настоящей проблемой, потому как меньше чем при CRF14 его просто размывало к чертям при любом psy-rd и deblock даже с tesa и subme=11, причём кодирование в 10бит размывало шум ещё сильнее, чем 8бит.
DotaSeal писал(а):
63738387Игросглаживатель
ты же всё равно будешь на ютуб заливать, а он раздавит твоё видео под свои жалкие мизерные настройки
+1
|
|
|
|
Игросглаживатель
Стаж: 12 лет 1 месяц Сообщений: 321
|
Игросглаживатель ·
27-Апр-14 12:49
(спустя 1 час 8 мин., ред. 27-Апр-14 12:49)
busoti4444 писал(а):
63733879Игросглаживатель
Без шумодава не получится оставить шум, исходное разрешение и сжать с меньшим битрейтом.
И всёравно надо искать компромисс.
Из заголовка темы я не разобрался в "psyRD + psyTrellis на пальцах" мне показалось что эти параметры могут помочь упаковать шум.
DotaSeal писал(а):
63738387Игросглаживатель
ты же всё равно будешь на ютуб заливать, а он раздавит твоё видео под свои жалкие мизерные настройки
здесь я выкладываю один раз закодированные, не с такими потерями.
|
|
|
|
Evgeny Crow
Стаж: 17 лет 3 месяца Сообщений: 623
|
Evgeny Crow ·
27-Апр-14 12:54
(спустя 4 мин., ред. 27-Апр-14 13:52)
Bill Ein писал(а):
А что дадут ваши азы фильтрации исходника, если полученное качество не удаётся закодировать?
Судя по размазне, которая на скриншотах - алгоритмы кодека X264 вы не поняли и на половину, азами фильтрации тут тоже не пахнет.
Т.к. если вы хотя бы уточните границы линий хорошим шарпом (без белых разводов), приберёте мусор MVDegrain + отдельный шумодав и стабилизируете тряску пленки/камеры (если она есть) - уже результат был бы значительно лучше визуально.
Кодеку нужны четкие границы и минимум шума (тогда его технологии будут работать на порядок эффективнее), на мультфильмах/анимэ - это идеальная среда для творчества, а также компактного и качественного визуально сжатия.
Да, будет не "как в оригинале", секта труАВЦ не оценит, но секта и не кодирует в 500 килобит, помните об этом.
Bill Ein писал(а):
В моей практике был пример, когда херовые серые градиенты удавалось восстановить только сильным шумом, а вот закодить этот шум стало настоящей проблемой, потому как меньше чем при CRF14 его просто размывало к чертям при любом psy-rd и deblock даже с tesa и subme=11, причём кодирование в 10бит размывало шум ещё сильнее, чем 8бит.
Добавление сильного шума - это крайняя мера, т.к. на эффективность сжатия в целом это отразится не лучшим образом.
Если без сильного шума не обойтись (хотя я в этом сильно сомневаюсь), "tune grain" вам в помощь.
|
|
|
|
busoti
Стаж: 13 лет 5 месяцев Сообщений: 2839
|
busoti ·
27-Апр-14 12:56
(спустя 2 мин., ред. 27-Апр-14 18:01)
Игросглаживатель
Настройками кодера нормально не сделаешь, и будешь пробы делать до скончания века. Проблема в том, что крутишь одно, а меняется много чего.
Я все проблемы решаю только фильтрами.
Цитата:
мне показалось что эти параметры могут помочь упаковать шум.
Чтобы прорисовать такой шум, надо немеряно битрейта, кодер ведь не волшебник. В любом случае, он будет делать это за счёт чего-то, т.е. что-то Вы потеряете.
На мой взгляд, можно попробовать только аккуратно снизить шум фильтром. Или довольствоваться высоким битрейтом, а соответственно и размером.
|
|
|
|
Bill Ein
Стаж: 15 лет 4 месяца Сообщений: 272
|
Bill Ein ·
27-Апр-14 14:38
(спустя 1 час 42 мин., ред. 27-Апр-14 14:38)
Evgeny Crow писал(а):
Судя по размазне, которая на скриншотах - алгоритмы кодека X264 вы не поняли и на половину, азами фильтрации тут тоже не пахнет.
Ах-ха-хах, а ничё что это пятикратное увеличение в фотошопе картинки, которая до это была двукратно увеличена в MPC? Я привёл такие скриншоты чтобы было видно как b-adapt=0 расхерачил градиенты и только.
Evgeny Crow писал(а):
если вы хотя бы уточните границы линий хорошим шарпом (без белых разводов)
aWarpSharp2(depth=2) - для HD современной анимации сойдёт?
Evgeny Crow писал(а):
приберёте мусор MVDegrain (хотя бы с анализом кадр вперёд / кадр назад)
Мусор от кодирования и предварительного дебандинга
Evgeny Crow писал(а):
стабилизируете тряску пленки/камеры (если она есть)
Тряски не было
Evgeny Crow писал(а):
Кодеку нужны четкие границы и минимум шума (тогда его технологии будут работать на порядок эффективнее), на мультфильмах/анимэ - это идеальная среда для творчества, а также компактного и качественного визуально сжатия.
Мои попытки почистить картинку как-то особо на вес не повлияли, потому как она итак была относительно чистой (если не считать дебандинг)
Evgeny Crow писал(а):
Да, будет не "как в оригинале", секта труАВЦ не оценит, но секта и не кодирует в 500 килобит, помните об этом.
Вижу вы через строчку читаете, посмотрите хотя бы последний пост на 45-й странице.
Bill Ein писал(а):
Добавление сильного шума - это крайняя мера, т.к. на эффективность сжатия в целом это отразится не лучшим образом.
Если без сильного шума не обойтись (хотя я в этом сильно сомневаюсь), "tune grain" вам в помощь.
И что Tune Grain даст? На какие настройки иксы он влияет? Вы можете дать на это ответ? Нет? А вот я вам подскажу:
psy_rd=1.00:0.25 / deblock=1:-2:-2 / aq=1:0.50 / qcomp=0.80 / deadzone=6,6 /
Итак:
1) при кодировании без mbtree бессмысленно повышать qcomp - это лишь увеличит вес файла впустую
2) deblock -2:-2 - на мой взгляд даёт очевидный профит лишь при кодировании в 10бит с b-adapt=1 и CRF15
3) psy_rd=1.00:0.25 - из моих экспериментов я сделал вывод о том, что первый параметр смещает пикселели через строчку по горизонтали, а второй по вертикали, создавая при этом нечто похожее на дизеринг по матрице Байера; повышать второй параметр допустимо для старой анимации, снятой на киноплёнку, для современной лично я смысла не увидел
4) aq=1:0.50 - местами вносит артефакты, но допустимо для старой анимации, снятой на киноплёнку, для современной лично я смысла не увидел и считаю, что aq=2:1 на порядок лучше
5) deadzone=6,6 - вот это единственное, что может реально помочь, правда для наибольшего профита надо поставить trellis=0 (о чём на Doom9 написано), а --tune grain этого не делает; более того эффективность deadzone зависит от кол-ва битрейта, т.е. чем ниже CRF - тем больше толку от deadzone, впрочем как и от остальных параметров.
|
|
|
|
Evgeny Crow
Стаж: 17 лет 3 месяца Сообщений: 623
|
Evgeny Crow ·
27-Апр-14 17:06
(спустя 2 часа 27 мин., ред. 28-Апр-14 04:18)
Bill Ein писал(а):
это пятикратное увеличение в фотошопе картинки, которая до это была двукратно увеличена в MPC
Да, и этого не следовало делать. Максимум - красным "карандашом" в пейнте или любом другом простейшем редакторе выделить косячную область.
Иначе мы тут даже не "по фотографии лечим", а по сглаженной картинке из фотошопа.
Bill Ein писал(а):
aWarpSharp2(depth=2) - для HD современной анимации сойдёт?
Сравните результаты aWarpSharp2 с комплексными фильтрами, например, LimitedSharpen.
На мультах/анимэ обычно даже большие значения выглядят вполне пристойно.
Но лучше подбирать по исходнику и наличию/отсутствию других фильтров в скрипте.
Bill Ein писал(а):
1) при кодировании без mbtree бессмысленно повышать qcomp - это лишь увеличит вес файла впустую
2) deblock -2:-2 - на мой взгляд даёт очевидный профит лишь при кодировании в 10бит с b-adapt=1 и CRF15
3) psy_rd=1.00:0.25 - из моих экспериментов я сделал вывод о том, что первый параметр смещает пикселели через строчку по горизонтали, а второй по вертикали, создавая при этом нечто похожее на дизеринг по матрице Байера; повышать второй параметр допустимо для старой анимации, снятой на киноплёнку, для современной лично я смысла не увидел
4) aq=1:0.50 - местами вносит артефакты, но допустимо для старой анимации, снятой на киноплёнку, для современной лично я смысла не увидел и считаю, что aq=2:1 на порядок лучше
5) deadzone=6,6 - вот это единственное, что может реально помочь, правда для наибольшего профита надо поставить trellis=0 (о чём на Doom9 написано), а --tune grain этого не делает
Видимо, сравнение в масштабе 10:1 вам не помогло и выводы вы сделали в корне неверные.
Да, индивидуальная корректировка настроек под исходник всегда приветствуется, tune grain только задаёт вектор "в какую сторону плясать", чтобы сохранить шум+детали.
1). Повышенный qcomp может давать в целом большую детальность (а бонусом большую вероятность лучше сохранить и шум), чем стандартный на аналогичном битрейте (и даже при меньших CRF). На фильмах от стандартных значений обычно больше пользы, чем вреда (за редким исключением).
2). Умеренно замятый deblock всегда даёт профиты по сохранению шума и мелкой детальности. Иногда ценой "артефактности", но визуально качество с хороших исходников и умеренном битрейте (не 500 килобит) почти всегда лучше. Исключение - это сжатие шумных/артефактных исходников без предварительной обработки, но если фильтровать деталей останется намного больше.
3). psy_rd=1.00 всегда даёт профиты по сохранению шума и мелкой детальности, это вообще основной козырь компактного/качественного кодирования X264. psy-trellis "0.25" - это уже мелкое косметическое дополнение, несущественное (можно вообще не пользоваться).
4). У aq=2:1 есть ещё свои косяки, поэтому в худшем случае aq=1:0.50 "+/-" можно рассматривать параллельно, но сравнивая результаты визуально.
5). Это не единственное, что может реально помочь.
Видимо, из всех этих заблуждений и получается так, что CRF14-15 вам не помогает.
|
|
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
27-Апр-14 19:30
(спустя 2 часа 24 мин.)
|
|
|
|
