|
|
|
jеnsen
Стаж: 15 лет 2 месяца Сообщений: 3228
|
jеnsen ·
26-Дек-24 16:28
(6 месяцев назад)
Если вы умеете крутить только этот один параметр, то да.
Но получение хорошего результата складывается из сочетания настроек. Црф там не главное, оно лишь задает планку, для соответствия которой вы крутите остальные настройки. Естественно, что слишком сильное увеличение црф до 20+ снижает планку настолько, что остальные настройки будут неспособны устранить видимые артефакты сжатия, ровно как и сильное уменьшение црф сделает другие настройки бесполезными и вы просто дуете битрейт больше, чем в исходнике. Важен баланс, повторяю.
|
|
|
|
Koo1
Стаж: 16 лет 2 месяца Сообщений: 1145
|
Koo1 ·
26-Дек-24 21:34
(спустя 5 часов)
Okay26
настройки по умолчанию у х264 дрянь, ориентироваться на них смысла нет
если исходить из наиболее выгодного соотношения размер-качество, то crf должен быть таким, примерно:
480р - 18
720р - 19
1080р - 20
почти визуальное без потерь - 16
|
|
|
|
CATFISH-2
Стаж: 15 лет 9 месяцев Сообщений: 2415
|
CATFISH-2 ·
26-Дек-24 23:31
(спустя 1 час 56 мин.)
jеnsen писал(а):
87171192высокой динамики требуется значение 16.5-18
вот мне лично хватает 18-22, а получать файл на выходе больше ,чем исходник , как бы дурняк 
Вообще-то я больше верю в 2PASS VBR, чем в непредсказуемый CBR.
|
|
|
|
jеnsen
Стаж: 15 лет 2 месяца Сообщений: 3228
|
jеnsen ·
26-Дек-24 23:45
(спустя 13 мин., ред. 26-Дек-24 23:45)
CATFISH-2 писал(а):
87173130а получать файл на выходе больше ,чем исходник , как бы дурняк
jеnsen писал(а):
87171316Но получение хорошего результата складывается из сочетания настроек. Црф там не главное, оно лишь задает планку, для соответствия которой вы крутите остальные настройки.
скрытый текст
jеnsen писал(а):
87171192у вас есть лог с квантами. Они не должны вылетать за 16-18 на зерне
https://rutr.life/forum/viewtopic.php?t=6251066
arxivariys писал(а):
83543611x265 [info]: frame I: 1926, Avg QP:14.20 kb/s: 42399.58
x265 [info]: frame P: 31320, Avg QP:15.13 kb/s: 32488.37
x265 [info]: frame B: 154115, Avg QP:16.62 kb/s: 21007.15
x265 [info]: Weighted P-Frames: Y:7.0% UV:2.0%
x265 [info]: Weighted B-Frames: Y:4.7% UV:0.5%
x265 [info]: consecutive B-frames: 14.3% 5.3% 6.6% 16.8% 9.1% 21.1% 4.9% 3.8% 3.9% 2.1% 1.3% 6.0% 1.6% 0.5% 0.9% 0.6% 1.2%
encoded 187361 frames in 276112.05s (0.68 fps), 23146.30 kb/s, Avg QP:16.35
arxivariys писал(а):
83543611Bit rate: 23.2 Mb/s
arxivariys писал(а):
83543611crf=18.0
Stream size: 21.1 GiB
Исходник примерно 100 гб. Экстраполируйте это к 1080 рипам и любым другим.
CATFISH-2 писал(а):
87173130CBR
crf это VBR
|
|
|
|
CATFISH-2
Стаж: 15 лет 9 месяцев Сообщений: 2415
|
CATFISH-2 ·
27-Дек-24 17:21
(спустя 17 часов)
CATFISH-2 писал(а):
87173130непредсказуемый CBR
ошибся ,непредсказуемый CRF
при ТАКОМ затратном кол-ве времени в 3.5 - 5 раз ожидается уменьшение размера хоть на треть меньше.
тот же х264 ставлю на макс. настройки, только ME - uneven multihexagonal, за 6-8 час на двух проходах
закодируется 3-4 фильма.
|
|
|
|
jеnsen
Стаж: 15 лет 2 месяца Сообщений: 3228
|
jеnsen ·
27-Дек-24 20:00
(спустя 2 часа 38 мин., ред. 27-Дек-24 20:00)
Все логично. Когда у нас (беатрис) были процессоры уровня Ivy Bridge и в дальнейшем всякие зеоны Haswell, мы кодировали в 264 рипы, скорость средняя была 3-5 фпс.
Прошло 12 лет и теперь мы кодируем на Raptor Lake или Ryzen и уже в 265 3-5 фпс, а если запустить 264, то можно увидеть 10-12 фпс.
Выйдет таки 266, будет 12 фпс на 265 и 3-5 на 266, сложность кодеков увеличивается практически вровень с производительностью железа. Это нормально.
|
|
|
|
CATFISH-2
Стаж: 15 лет 9 месяцев Сообщений: 2415
|
CATFISH-2 ·
27-Дек-24 22:28
(спустя 2 часа 28 мин.)
jеnsen писал(а):
87176778Все логично
ну да, хочется чо-нить потестить, а кодируется кин на 33% ,осталось ещё 7.5 часов.
-----------------------------------
--ctu, -s <64|32|16> вот если поставить вместо 64 -- 48 ,прирост скорости ожидаем?
|
|
|
|
jеnsen
Стаж: 15 лет 2 месяца Сообщений: 3228
|
jеnsen ·
28-Дек-24 00:44
(спустя 2 часа 16 мин., ред. 28-Дек-24 00:44)
CATFISH-2 писал(а):
87177419ожидаем?
Ожидаема ошибка. Вам же написали допустимые значения, 64|32|16.
Для повышения скорости вам нужно сменить железо. Но, как я уже говорил, 6-7-8 фпс для 1080 на 265 на зеоне в 2024 это очень хороший результат. Выше головы не прыгнуть, только раскошеливаться на тредрипер и так далее.
|
|
|
|
Okay26
Стаж: 14 лет Сообщений: 206
|
Okay26 ·
28-Дек-24 15:46
(спустя 15 часов, ред. 28-Дек-24 15:46)
мне этот спор ниочем напомнил о скачивание дорожек с ютуба, пережатием их в увеличеный вес и выдавая за flac
https://rutr.life/forum/viewtopic.php?t=5696731 - вот эта раздача была сжата handbrake при определенном CRF, хотелось бы узнать экспертное мнение по поводу появления артефактов на черном и т.д
угадайте какой тут CRF и сколько фильм весит после сжатия
скрытый текст
экспертное мнение человека с ЛУПОЙ не учитывается, никто фильмы смотреть не будет в приближении 200+
|
|
|
|
jеnsen
Стаж: 15 лет 2 месяца Сообщений: 3228
|
jеnsen ·
28-Дек-24 16:25
(спустя 39 мин.)
Балки моста в верхнем левом углу кадра превратились в месиво пикселей, но это ничего же, да?
|
|
|
|
halo_cool
Стаж: 16 лет 9 месяцев Сообщений: 528
|
halo_cool ·
28-Дек-24 16:39
(спустя 13 мин.)
Okay26 писал(а):
87180184мне этот спор ниочем напомнил о скачивание дорожек с ютуба, пережатием их в увеличеный вес и выдавая за flac
https://rutr.life/forum/viewtopic.php?t=5696731 - вот эта раздача была сжата handbrake при определенном CRF, хотелось бы узнать экспертное мнение по поводу появления артефактов на черном и т.д
угадайте какой тут CRF и сколько фильм весит после сжатия
скрытый текст
экспертное мнение человека с ЛУПОЙ не учитывается, никто фильмы смотреть не будет в приближении 200+
Каким кодеком жалось и в какой размер/средний битрейт?
|
|
|
|
73ultras
Стаж: 14 лет 9 месяцев Сообщений: 401
|
73ultras ·
28-Дек-24 19:43
(спустя 3 часа, ред. 28-Дек-24 19:43)
Не очень понимаю, что в теме, посвященной пережиманию анимации, забыли люди, пержимающие игровое кино.
Вижу, что Дженсен делится опытом кодирования анимации (и судя по релизам команды, преимущественно современной), а ему парируют люди, хендбрейкающие старые зернистые фильмы.
Как бы, в кино и фреймов больше, и наполнение кадра сложнее. И при общих равных битрейты выше, размеры больше, время кодирования дольше.
И в случае домашних коллекций кодирование в битрейт наверно имеет смысл. Лично я в бюджетных хевках кина с ~6к битрейта, сделанных популярными риперами на пиратбае очевидных изъянов не вижу, с включенным cutree "визуальной энергии" там столько, что за пикселями не поохотишься, а с 2+ метров, да на телевизоре, много чего не видно. Только один вопрос назревает, нахрена вы в принципе кодируете то, что многократно сделано до вас? На рутрекере просто оно не релизится.
Быстрее и проще скачать с иностранных открытых источников и натянуть на рип нравящуюся озвучку/даб/русаб.
|
|
|
|
jеnsen
Стаж: 15 лет 2 месяца Сообщений: 3228
|
jеnsen ·
28-Дек-24 20:37
(спустя 54 мин., ред. 28-Дек-24 20:37)
Да нет, аниме или кино это совсем не важно, отличие только в необходимости фильтрации, в кино она обычно не нужна. А жмется контент по одинаковым принципам. Это же не флеш анимация, в аниме особенно современном куча динамики и сложное освещение в кадрах с деталями в темноте. В аниме тоже есть фильмы по 2+ часа и с зерном, добавленным ради дизеринга на 8 бит видео у бд и есть куча старых аниме, в виде сканов с пленки. Причем порой 16 мм, а там зерно очень… гм… зернистое.
Так что я поясняю базовые принципы, которые описаны в основной статье этой темы. Что для хорошего сжатия зерна или чистого изображения недостаточно крутить только црф, это не простой 264, у хевка порядка 30 настроек влияющих на итоговый результат очень сильно. Но люди не понимая, говорят «если снизить значение црф, то битрейт будет больше исходника». В шапке темы есть даже пресеты для разных типов видео (и без разницы, аниме или кино, это видео и базовые настройки одинаковые, отличаются лишь значения aq по сути) которые можно использовать как базу для дальнейшего «кручения». Также я привел пример хорошего кодирования фильма в 265 несколькими сообщениями выше, с настройками, но ведь гораздо проще просто крутить црф, да?)
Хотя люди, заявляющие «я у себя все жму с црф 27, чтоб больше уместилось на хард, а вы тут фигней занимаетесь» скорее всего считают это ерундой, я уже привык, но это как раз мотивирует меня доносить информацию «как нужно и как не нужно делать» до основной массы, читающих эту тему, дабы они получали верную информацию и не удивлялись потом статусу закрыто, если вдруг принесут «црф 27 на зерне» рип на трекер.
|
|
|
|
johnowenemmet
Стаж: 15 лет 4 месяца Сообщений: 172
|
johnowenemmet ·
28-Дек-24 21:07
(спустя 29 мин.)
Я совсем не анимешник, да и с фильмами так уж, лишь чутка баловства имею, не более того, но крайне сложно будет перечислить хотя бы с десяток рипов с crf выше 22 и чтобы без видимых артефактов вышли (но современные сериалы с вылизанной картинкой не в счёт, это другое, понимать надо, там 22 +- 0,5 это норма).
27 говорите... ну да, ну да, пошёл я...
|
|
|
|
73ultras
Стаж: 14 лет 9 месяцев Сообщений: 401
|
73ultras ·
28-Дек-24 22:12
(спустя 1 час 4 мин., ред. 28-Дек-24 22:12)
johnowenemmet писал(а):
87181646но крайне сложно будет перечислить хотя бы с десяток рипов с crf выше 22 и чтобы без видимых артефактов вышли
Согласен.
Я далеко не шар в плане кодирования, вникать начал год или два назад как раз с этой темы, преимущественно ради аним, обделенных вниманием энкодеров.
Так же я сторонник решений не "как в исходнике", а скорее "разумный баланс размер/качество". И в моем случае для фильмов эти значения лежат в пределах crf 17.5-20 с размерами файлов 3.5-6.5 гб -- как будто бы вполне экономно, больше жать ни к чему. И то что тут пишут, про какое-то "плацебо на crf 17" и "битрейты больше, чем в исходнике" (для фильма вес бд ремукса 20-30 гб), кроме недоумения, ничего не вызывают. Очевидно, дело не в crf.
|
|
|
|
Okay26
Стаж: 14 лет Сообщений: 206
|
Okay26 ·
28-Дек-24 23:15
(спустя 1 час 2 мин.)
jеnsen писал(а):
87180353Балки моста в верхнем левом углу кадра превратились в месиво пикселей
и не удивлялись потом статусу закрыто, если вдруг принесут «црф 27 на зерне» рип на трекер.
бхаха, я эту сцену сравнивал на телеке, и даже сразу не заметил, что в оригинале черное пятно, что в сжатой версии черное пятно
мне приносить ничего не надо, я себе сжимаю чтоб больше влезло и в качестве особо не теряло и вот именно что качать отсюда рипы 2 гиговые
скрытый текст
да да, я сжал его в качестве 28(!!!) и весит он 3 гига
или откуда либо еще я смысла не вижу, потому что там не HEVC а AVC который кубоёбит с маленьким битрейтом, либо уменьшают вес еще за счет разрешения, но извините, если телевизор еще разгладит небольшие пиксели или просто изза его цветопередачи не увидишь "месиво" это еще ладно, но вот растягивать и разглаживать это будет мыльный треш
это как из того же примера что я кидал с наруто ссылку, резрешение большое но качество сжатие тоже высокое, на компе смотреть конечно так себе, а на умном телевизоре вполне гуд.
до этого качал наруто в маленьком разрешении, и даже на телевизоре смотреть это было невозможно, тьфу
|
|
|
|
halo_cool
Стаж: 16 лет 9 месяцев Сообщений: 528
|
halo_cool ·
28-Дек-24 23:39
(спустя 24 мин.)
jеnsen
А вообще в качестве тскть расстановок точек над i, вы сами как считаете?
До какого момента сжатие, условно, "допустимо"?
В общем-то есть такие исходники 1080р, которые 30 мегабит до последнего байта жрут и не давятся, и даже на дешманском телевизоре (достаточно большом, естественно) разницу между ними и 12-15 ккбпсами хевка с тонкими настройками разницу можно рассмотреть (если знать, куда смотреть, но тем не менее).
С другой стороны, есть например такая чудная штука, как дешманские же китайские проекторы в 720p. Эти ребята позволяют получить вполне себе киношное впечатление на достаточно большом экране и спокойно увидеть новые детали, на которые не обращаешь внимания в меньшем размере, в уже сто раз просмотренных казалось бы лентах. На этих ребятах прекрасно видно ужасы старых дивиксов и квадратура низкобитрейтовых авц. Но стоит взять битрейт выше, чем делает в среднем какой-нибудь yify, и всё становится прекрасно.
У самого рутрекера на это счёт достаточно жёсткие и, на мой вкус, несколько устаревшие правила.
|
|
|
|
jеnsen
Стаж: 15 лет 2 месяца Сообщений: 3228
|
jеnsen ·
29-Дек-24 00:09
(спустя 30 мин., ред. 29-Дек-24 00:09)
halo_cool писал(а):
87182300До какого момента сжатие, условно, "допустимо"?
До момента "пока вам нравится" если вы делаете сугубо для себя. Ну а если прям по чесноку, то рип должен быть максимально возможно похож на исходник, но меньшего размера. Вы должны экономить на незаметных вещах, допущение видимых артефактов и потери деталей не приветствуется любым нормальным человеком. Экономить на незаметных вещах = грамотно использовать настройки и позволять кодеку чуток "подтирать" текстурки и детальки в динамике и максимально сохранять статику. Согласитесь, малоприятно, когда сильное сжатие вызывает "шевеление кусков блочности" на заднем плане в темной сцене крупным планом. Вы такое можете видеть на ютубе с его адским сжатием, когда градиенты превращаются в месиво блочности и бандинга и оно остается подвижным и "мельтешит".
halo_cool писал(а):
87182300есть такие исходники 1080р, которые 30 мегабит до последнего байта жрут и не давятся
Зерно всегда плохо сжимается, там нужно быть более "агрессивным" по настройкам, но это не означает установку црф 28, достаточно 18, кутри и если нужно, зонами принудительно понизить в особо сложных местах.
пример моих изворотов в особо сложном случае
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 40 min
Bit rate : 18.6 Mb/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.374
Stream size : 13.0 GiB (96%)
Title : BDrip by Jensen
Writing library : x265 3.4+40-b86c0196a:[DJATOM's Mod][Windows][GCC 10.2.1][64 bit] 10bit
Encoding settings : cpuid=1049583 / frame-threads=16 / numa-pools=24,24 / wpp / pmode / pme / no-psnr / no-ssim / log-level=2 / csv / csv-log-level=0 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=144552 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=240 / gop-lookahead=0 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=16 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=5 / limit-refs=1 / no-limit-modes / me=3 / subme=7 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / weightb / analyze-src-pics / deblock=1:-1 / no-sao / no-sao-non-deblock / rd=5 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=4.00 / no-rd-refine / no-lossless / cbqpoffs=-2 / crqpoffs=-2 / rc=crf / crf=15.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=4 / aq-strength=1.02 / cutree / zone-count=12 / zones: / start-frame=0 / end-frame=967 / bitrate-factor=2.000000 / zones: / start-frame=968 / end-frame=3042 / bitrate-factor=2.000000 / zones: / start-frame=5300 / end-frame=5344 / bitrate-factor=1.700000 / zones: / start-frame=9812 / end-frame=10009 / bitrate-factor=1.700000 / zones: / start-frame=10103 / end-frame=10147 / bitrate-factor=1.700000 / zones: / start-frame=10289 / end-frame=10324 / bitrate-factor=1.700000 / zones: / start-frame=10407 / end-frame=10508 / bitrate-factor=1.700000 / zones: / start-frame=10528 / end-frame=11444 / bitrate-factor=1.700000 / zones: / start-frame=73011 / end-frame=74603 / bitrate-factor=0.840000 / zones: / start-frame=75421 / end-frame=76118 / bitrate-factor=0.840000 / zones: / start-frame=103729 / end-frame=103793 / bitrate-factor=1.700000 / zones: / start-frame=139750 / end-frame=144550 / bitrate-factor=1.700000 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / 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 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=4 / refine-inter=0 / refine-mv=3 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=2.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Language : Japanese
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
И ничего, 48 мегабит на бд (на этом издании скан пленки не шумодавили и загнали в максимально возможный для бд битрейт, так как звуковая дорожка одна стерео и болванка бд 50) удалось рипнуть в 18, поколдовав ручками с зонами и покрутив остальные настройки, практически не затирая детали, но все же чутка размыв текстуру зерна принудительным ручным увеличением сжатия в нужных (особо зернистых) местах, что визуально не сильно заметно, если "попиксельно" на зуме не сравнивать с исходником. Хотя надо было просто црф 28 поставить и все. 
halo_cool писал(а):
87182300У самого рутрекера на это счёт достаточно жёсткие и, на мой вкус, несколько устаревшие правила.
Зато эти правила позволяют собирать тут архив в хорошем качестве, а различные пережатки люди делают сами для себя. Так что как посмотреть. Устаревшие и жесткие, но работают.
|
|
|
|
Okay26
Стаж: 14 лет Сообщений: 206
|
Okay26 ·
29-Дек-24 12:00
(спустя 11 часов)
смейся смейся
а ведь кто-то же притаскивает сюда свой avc 4гиговый вот с таким "месивом" и ничего, не закрывают
|
|
|
|
halo_cool
Стаж: 16 лет 9 месяцев Сообщений: 528
|
halo_cool ·
29-Дек-24 16:14
(спустя 4 часа, ред. 29-Дек-24 16:14)
jеnsen
Ну да, я собственно тоже об этом же.
Хевк значительно лучше авц в плане визуала в том смысле, что там где раньше были жуткие квадраты, теперь мыло/мешанина (правда, он иногда грешит в анимациях огромными шумными квадратами на лицах, это прям жесть). При битрейтах 5к+ эти мыло-мешанина (и лесенка вокруг движущихся объектов, которая остаётся практически при любом сжатии) видны только если глаз уже сильно намётан и знаешь, где искать (а зачем это обычному пользователю) либо на дорогом-качественном оборудовании (которое тоже далеко не у всех есть).
Такое же мыло дают, кстати, 720р авц 8+гиговые рипы, которые здесь в разделе "кино" в почёте, и вот этого я вообще не понимаю. Хевк 1080р с тем же битрейтом даст больше деталей (но кодить, конечно, дольше)
С 40 до 18 мегабит результат изумительный (если исходник 1080р, а не 4к). Но 18 мегабит по размеру – это уже бдремукс средне-мелкий.
А некоторые исходники вообще простора для манёвра не оставляют – понижение битрейта на 5к не стоит затраченных усилий, да и любой любитель качества посчитает нужным кинуть калом в энкодера.
Помню, кстати, был скрипт для ависинта, который резал мелкие куски из всего исходника и кодировал их. Что позволяло предварительно оценить нужные параметры без кодирования всего видеоряда.
Никому такого для ффмпег не попадалось? А то при кодировании одного сложного эпизода кодек ему вжаривает битрейт выше крыши и всё прекрасно. А потом при кодировании всего ряда выясняется, что в изменившихся обстоятельствах кодек посчитал, что эта сцена не такая и ценная, и дал ей битрейт джва. Прям хоть вручную кодь отдельное эпизоды да склеивай потом.
|
|
|
|
jеnsen
Стаж: 15 лет 2 месяца Сообщений: 3228
|
jеnsen ·
29-Дек-24 18:03
(спустя 1 час 48 мин.)
Okay26
Это вебка, а не бд.
|
|
|
|
dio669
Стаж: 15 лет 5 месяцев Сообщений: 1229
|
dio669 ·
11-Янв-25 14:12
(спустя 12 дней, ред. 11-Янв-25 14:12)
Коллеги, а есть ли в перспективе нормальные кодеки с наложением зерна в виде отдельной таблицы? Захотелось добавить эффект плёнки, в итоге объём с 4гб улетает до 20гб и выше. При этом я могу без какой либо нагрузки на железо смотреть это же видео добавив пару строк ависинта с генераторами шума. Отдавать такой объём на оцифровку мух в наше время это какой то кринж. Всего то надо в заголовок добавить образец или описание алгоритма, вес которого в сотни килобайт всего. Тут даже не нужны эти ai, которыми сейчас пытаются оптимизировать сжатие-распаковку. То есть зерно не должно быть представлено в графической форме вообще, только цифровое описание.
|
|
|
|
p1zrv
Стаж: 10 лет 6 месяцев Сообщений: 2808
|
p1zrv ·
11-Янв-25 19:30
(спустя 5 часов, ред. 11-Янв-25 19:32)
dio669
Ощущение, что это вопрос, на который вы уже знаете ответ. Но все равно отвечу - grav1synth.
Из того что я видел оно не очень. [2ndfire] Blue Gale Xabungle [BD][1080p][AV1][10bit], например.
|
|
|
|
dio669
Стаж: 15 лет 5 месяцев Сообщений: 1229
|
dio669 ·
11-Янв-25 21:28
(спустя 1 час 57 мин.)
p1zrv писал(а):
87242950Ощущение, что это вопрос, на который вы уже знаете ответ.
Вы мне льстите. Попробую разобраться. Если я правильно понимаю, это что-то вроде надстройки для AV1 кодека...
|
|
|
|
73ultras
Стаж: 14 лет 9 месяцев Сообщений: 401
|
73ultras ·
12-Янв-25 16:19
(спустя 18 часов)
p1zrv писал(а):
87242950Из того что я видел оно не очень. [2ndfire] Blue Gale Xabungle [BD][1080p][AV1][10bit], например.
А [Sokudo] Goku Midnight Eye I & II 1989 [1080p BD AV1] не оно? Как будто бы хорошее.
|
|
|
|
p1zrv
Стаж: 10 лет 6 месяцев Сообщений: 2808
|
p1zrv ·
12-Янв-25 19:34
(спустя 3 часа, ред. 12-Янв-25 19:34)
73ultras
Скачать не получается, глянул скрины на animetosho - выглядит получше, но как именно оно смотрится при воспроизведение не знаю.
В релизах [2ndfire] чётко видно паттерн/блоки "зерна" и смотрится оно не очень
Скачалось немного, тоже самое. Вот здесь это "зерно" хорошо выглядит https://waveletbeam.com/index.php/av1-film-grain-synthesis (хоть паттерн и виден при остановке, но при воспроизведении он незаметен)
[Sokudo] Goku Midnight Eye 1989 S01E01 [1080p BD AV1][dual audio]
|
|
|
|
73ultras
Стаж: 14 лет 9 месяцев Сообщений: 401
|
73ultras ·
13-Янв-25 05:57
(спустя 10 часов, ред. 13-Янв-25 05:57)
p1zrv писал(а):
87247559В релизах [2ndfire] чётко видно паттерн/блоки "зерна" и смотрится оно не очень
Меня скорее смущает, что там видно, что за зерном скрывается апскейленный исходик.
p1zrv писал(а):
87247559Скачалось немного, тоже самое.
По-моему достаточно похоже на исходное зерно с последних дискотековских блюреев (которое вероятно тоже не плёночное).
Сэмпл напоминает результат работы этого фильтра https://github.com/Dogway/Avisynth-Scripts/blob/master/FilmGrain%2B.avsi с пресетом плёнки.
Не уверен, что оно так же выигрышно смотрится на анимации, как на игровом кине.
|
|
|
|
p1zrv
Стаж: 10 лет 6 месяцев Сообщений: 2808
|
p1zrv ·
13-Янв-25 12:15
(спустя 6 часов, ред. 13-Янв-25 12:15)
73ultras писал(а):
87249955По-моему достаточно похоже на исходное зерно с последних дискотековских блюреев (которое вероятно тоже не плёночное).
У меня претензии только к тому что при воспроизведении я вижу блоки этого зерна (паттерн), а не хаотичное зерно как в исходнике или в том примере что я скинул.
|
|
|
|
dio669
Стаж: 15 лет 5 месяцев Сообщений: 1229
|
dio669 ·
17-Янв-25 01:23
(спустя 3 дня, ред. 17-Янв-25 01:23)
Не осилил grav1synth, как и во что этот код надо собирать, и чем. Можно ли из него получить исполняемый exe или это вообще под линукс %) Может что-то подобное догадаются встроить в ffmpeg когда-нибудь.
Если правильно понял, без grav1synth нормально зерно не добавить. А сам AV1 не умеет подставлять нужное зерно, если оно не присутствует в исходнике - нельзя просканировать материал А и результат добавить в материал Б. Он тупо сканирует, потом запускает внутренний денойзер, и накладывает полученную схему зерна на им же оставленный фарш, лишний раз убив материал. Кто это вообще придумал.)) Понятно что сделано для однокнопочных решений в первую очередь, но вот уже есть очищенный от шума материал, нужно в него воткнуть таблицу с зерном, а вот фик.)
|
|
|
|
p1zrv
Стаж: 10 лет 6 месяцев Сообщений: 2808
|
p1zrv ·
17-Янв-25 01:25
(спустя 2 мин., ред. 17-Янв-25 01:26)
dio669
Если хотите, то можем в тг поговорить об этом (напишите в личке на рутрекере, скину ник; ну или вы свой). Я увидел в релизах на гите "4 tags" и подумал там есть эксешник, но, как оказалось, нет, а до этого не проверял. Я взял в одном из релизов 2ndfire на ня, добавляет его для того чтобы убирать зерно, если кому то не понравится.
dio669 писал(а):
87267105А сам AV1 не умеет подставлять нужное зерно, если оно не присутствует в исходнике. То есть ему нужно просканировать материал, потом запустить внутренний денойзер, и наложить полученное зерно на им же оставленный фарш, лишний раз убив материал. Кто это вообще придумал.))
Я так понял, что там можно сделать разницу между двумя видео, чтобы получить зерно (по сути кодишь без зерна, а потом через grav1synth делаешь разницу и добавляешь таблицу к видео без зерна).
Цитата:
Понятно что сделано для однокнопочных решений в первую очередь, но вот уже есть очищенный от шума материал, нужно в него воткнуть таблицу с зерном, а вот фик.)
Думаю, можно воткнуть. Достаточно черного видео и черного видео с зерном, сделать разницу с помощью grav1synth и потом приложить к другому видео (?).
grav1synth
Commands:
inspect Outputs a film grain table corresponding to a given AV1 video, or reports if there is no film grain information
apply Applies film grain from a table file to a given AV1 video, and outputs it at a given `output` path
generate Generates photon-noise-based film grain based on a given ISO value, adds it to a given AV1 video, and outputs it at a given `output` path
remove Removes all film grain from a given AV1 video, and outputs it at a given `output` path
diff Compares a source video and a denoised video and generates a film grain table based on the difference between them. This will provide the most accurate estimation of source film grain
help Print this message or the help of the given subcommand(s)
Options:
-h, --help Print help
|
|
|
|
