Last comments Artofeel

Акита
оценил :D
фаллометрия — двигатель прогресса!

trampler wrote:
Там где интерполяция лажает, нужно маскить объект

типа маски для твикстора? я так и не понял что он с ними делает...буду благодарен за годный тутор

trampler wrote:
и оставлять в исходных 8-12 фпс

ну так и было сделано, никаких дублей

vivan wrote:
Что значит "скрываться"?

т.е. там не то что пишет какая то программа-информатор или рендер
например, кто то в вики написал
http://en.wikipedia.org/wiki/Chroma_subsampling#4:4:4_R.27G.27B.27_.28no_subsampling.29

wiki wrote:
Note that "4:4:4" may instead be referring to R'G'B' color space, which implicitly does not have any chroma subsampling at all. Formats such as HDCAM SR can record 4:4:4 R'G'B' over dual-link HD-SDI.

vivan wrote:
Потому, что 4:4:4 с использовазнием матрицы GBR эквивалентно обычному RGB.

иными словами:
у меня RGB, а не YUV 4:4:4

vivan wrote:
Если добавить к этому неадекватные настройки

настройики одинаковы (практически) для всех версиий, у RGB только коэфициент сжатия больше.

btw, если я закодирую х264 lossless (crf 0) в RGB, то после декодирования я получу файл _ПОБИТОВО_ совпадающий с оригинальным, если я закодирую в YUV лосслесс, то я получу совершенно другие данные...
Мы просто оперируем разными взглядами, ты не автор, ты ничего не создавал, тебе меня не понять, ты опираешься на какие-то ограничивающие стандарты кодирования видео-данных, не трать своё время, ты все равно не переубедишь меня. :)

upd:
выяснил почему chroma qp offset минусуется...
это все --psy-rd, чем сильнее значение тем сильнее минус

vivan wrote:
Во-первых тебе медиинфо пишет:
Во-вторых тебе madvr пишет:

ну так, под 4:4:4 может скрываться RGB, не так разве?

vivan wrote:
В-третих H.264 ничего, кроме YUV c 4:2:0/4:2:2/4:4:4 сабсемплингом не поддерживает.

если он не поддерживает, тогда почему размер раздувается?

vivan wrote:
Т.е. 4:2:0 ргб тебя не удивляет?)

да я инпут имел ввиду
раз синт его поддерживает, тогда не проблема

vivan wrote:
Еще раз повторю, что RGB - это 4:4:4 YUV + матрица BGR

откуда такие сведения? пруфлинк пожалуйста.

vivan wrote:
Я предлагаю дать иксу на вход 16 бит (можно и 10, разницы не будет) и закодить им в 10

что то я сомневаюсь что он закодит "честные" 10 бит, мне кажется отдихтерит в 8 и сделает магические 10, и фиг ты этот проверишь...
алсо, что то я не слыхал о RGB на 10\10\10, там же можно только по 8 или 16 или 32

vivan wrote:
Это матрица, которая в поток прописывается.

да это понятно, просто не совсем понятно, как можно было написать конверт цветов и при этом не давать возможность указать матрицу...

vivan wrote:
Нестыковочка-то.

всмысле? я вывел 16 и отдихтерил в 8 -> закодил
что ты предлагаешь? закодить 16? ну тогда оно вообще будет наверно весить...плюс у всех моники 8битные, толку.

vivan wrote:
а тот радостно использует для этого Rec601 матрицу.

O_O
а разве не ту которую указываешь в --colormatrix !? или --colorprim или еще чо там, какая то..
эммм...фак..моя вера в здравый ум разрабов х264, пошатнулась...
еще одно доказательство, нах#й YUV

vivan wrote:
А теперь расскажи мне в чем проблема вывести >8 бит.

а я и вывел, ты вообще читал что я писал?

vivan wrote:
И сочность битностью не определяется, лол.

а определяется она кодингом, да? ...10bit поколение...

vivan wrote:
а последняя - бесполезные 4:2:2.

предпоследняя, последняя (внешняя) обычная YUV 4:2:0
не знаю, кому в голову взбрело, перекодировать уже закодированное видео и ставить это основной ссылкой...

vivan wrote:
Только хомячье тебя начитается, а потом такой хрени еще больше будет.

угугу, и мы захватим мир, и тогда ты уже нас не остановишь! муухахахахахаха ха

Alkatraz234 wrote:
Откуда столько восторга, не пойму?..

Welcome to the AMVNews!
тут народ не требовательный :)

neko lover wrote:
апскейл же был даже больше 720р, чтоб камеру сделать?

да, апскейл был до 2560х1440 (более красивше линии от варшарпа)
проект в АЕ был 1920х1080 (для более легкой интеграции БДрипа в будущем)
ну и зум, кое где, в районе 15% есть
насчет камеры, то она полностью из сорца
например, момент 0:08-0:19, это таймремап твикстором, через граф

neko lover wrote:
1:11 как робот дергается

дааа, переборщил :)

vivan wrote:
ты вообще читал что я писал?

так, бегло.

vivan wrote:
Там где про всякие блюмы-фигблюмы было.

так ты про Glow? это AE'шный фильтр работаюший _хорошо_ исключительно в 16-32 битах на канал
т.е. читай, я расширил цветовой сигнал
этого мало, чтобы получить более сочную картинку от оригинала?

vivan wrote:
И раздувание битрейта в 5 раз без заметной пользы это лишь подтверждает.

у тебя точно ргбатхерт, RGB версия лишь одна из 3-x возможных для скачивания
и вообще, чо хочу то и делаю :P

Alkatraz234 wrote:
Уберите из работы апскейл

хмм..значиццо апскейл тебя заинтриговал да? :D
хотя чо в нем такого технического, я не пойму..

Weestwoood wrote:
А сам исходник... Только 4 эпизода?

да
точнее, только 3 эпизода здесь

Bill Ein wrote:
Кроме того что это апскейл из webrip 640х360, так ещё и по качеству картинки тянет от силы на HDTVrip upscale 2000kbps, так ещё и аж до 720p, так ещё и в РГБ, так и всего-то 250МБ при 30fps.
В связи с чем наворачивается вопрос: зачем и для чего все эти танцы?
Бьюсь об заклад, что я бы сделал апскейл качественнее и получил бы после кодирования в YUV 10бит картинку лучше, а вес меньше.

just genius. teach me like a boss.
билли, ты не перестаешь продлевать мне жизнь. спасибо тебе за это. :)

vivan wrote:
Есть скрин с видео. В ргб. Ависинтом его в yv12, а madVRом его обратно в ргб.

хорошо, я кажется понял о чем ты.
давай тогда так:
есть подленник картины
есть копия этой картины
что ты выберешь?

vivan wrote:
Кодирование rgb - это костыль над 4:4:4 YUV и работает он просто - три канала (R, G, B) считаются за Y, Cb, Cr.

хмм..в любом случае, я chroma-qp-offset не трогал, это позоже какой то твик, призванный улучшить хрому на 4:2:2 и 4:4:4
соответсвенно на RGB он нафиг не нужен и сдедовательно это баг х264...

vivan wrote:
Ты ж сам заявил, что у тебя там 100500 бит внутри.

где!? О_О

Bubusiateenka wrote:
Как жить то теперь дальше, скажи, а?

ой да ладно, как будто я раньше не халтурил :)

vivan wrote:
Чтож еще варпшарпа не набросил?

набросил..
короч, весь скрипт

avs wrote:
GradFun2DBmod(thr=1.6)
FFT3DGPU(sigma=1.0,beta=0.75)
nnedi3_rpow2(rfactor=4, nsize=0, nns=4, qual=2, etype=0, pscrn=4, threads=4, opt=0)
aWarp4(Spline36Resize(width*4, height*4, 0.375, 0.375), aSobel().aBlur(), depth=3)
aWarpSharp2(thresh=100, type=0, blur=2, depth=24, chroma=4)

vivan wrote:
чо?

ты показал пример конвертирования, "туда-сюда", а где обработка, после "туда" ?

vivan wrote:
Только, вот, тут в качестве люмы у тебя выступает канал R (скорее всего), а хромы - G и B. В результате у них разный уровень качества. Мило, не правда ли?

это лично твоя теория? ты считаешь что разрабы х264 настолько глупы, чтобы при кодировании RGB отключать все что связано YV разверткой?

vivan wrote:
Икс вполне себе 16-битные источники потребляет.

ну я это обдумывал, да. RGB в 16 битах на канал, да. Однозначно, в будущем. :3
Ты же предлагаешь 8 бит в магические 10 превратить. Такое годится на низком битрейте.

Bubusiateenka wrote:
Ну а точнее: артофил, что за дела?

что? мне нельзя схалтурить, что ли? :D

Turbo
Зеркало 1: 720p (RGB)
Зеркало 2: 432p (YUV 4:2:2)
Зеркало 3: 720p

vivan wrote:
А что из них превратило его в такое жуткое мыло?

FFT3DGPU probably
цель была получить чистую картинку для апскейла, не вижу ничего криминального в такой гладкости.

vivan wrote:
Один из них скрин с видео, второй - с скрипта, конвертящего в yv12 (и обратно madVRом)

и чо?
а часть отвечающая за обработку?

vivan wrote:
ты в курсе что такое crhoma-qp-offset, зачем оно у тебя стоит в -6 и к чему оно приводит?

понятия не имею, давай объясняй мне. Быстро, решительно.
и я не знаю, где ты увидел -6 (версия по основной ссылке, не моя, я за ее качество не отвечаю)

vivan wrote:
а чтож не скормить все это счастье 10битному иксу?

и получить рандом-дихтеринг? нет, спасибо.

vivan wrote:
Лол, это делается одной строчкой в скрипте.

у нубов, да :)

vivan wrote:
Только, вот, сорец - все тот же yv12, да еще и 640х360 (=> хрома 320x180).

только вот сорец был обработан Glow в 16 битах на канал и выведен в 64 бита (ну и в итоге отдихтерен в 8 бит на канал)

vivan wrote:
И чеж не анкомпрессед тогда? Оно ж еще оригинальней?

оригинальнее то оригинальнее, но не доступнее..

admin wrote:
Зеркало 1: Высокое качество (расширенный цветовой диапазон) YUV 4:2:2 720p
Зеркало 2: Высокое качество (расширенный цветовой диапазон) YUV 4:2:2 432p

удали уже эти строчки...
если сам не понимаешь что к чему, то не нужно запутывать зрителя (пусть он по старинке "ведется" на размер файла)

Disengager wrote:
Тут реально всего 30 фпс?

да
просто обычно в аниме всего 8-12 fps на анимации. Тут же все (ну или почти все) доведено до 30 фпс

vivan wrote:
Ну серьезно, тут ргб только размер раздувает.

У тебя ргбатхерт?
RGB это оригинальное изображение
YUV это представление об оригинальном изображении, которое нужно с определенной долей погрешности (и отсебятиной) восстановить
капиш?
и я же сделал обычную версию (и не только)
не хочешь, не качай. Я всего лишь предоставил выбор.

denismax wrote:
Правда иногда это приводит к некоторым рывкам в анимации и очень сомнительно, что это такой ход.

да, кое где скосячил, плюс исходник не лучшего качества...однозначно, после выхода БД, будет ремастер.

Sintara wrote:
Поглазела работу , посмотрела исходник . А де работа то ?

а нафига она _здесь_? :)
вон, в прошлогоднем, была куча работы..и чо?

seriy wrote:
Надеюсь здесь не тупо пересказ исходника ?

самый, что не наесть, лютый :D

MooNi wrote:
Где ж ты такое большое разрешение раздобыл?

апскейл же
что не видно? :D

MooNi wrote:
Жаль, что так мало сняли, эх...

ну так это же спешелы
вроде работа над полнометражкой закончена, и сейчас она пойдет по фестивалям\кинотеатрам Японии...так что остается ждать выхода БД.

>>Зеркало 2: Высокое качество (расширенный цветовой диапазон) RGB 432p
тут все таки что то не то написано...не RGB, а YUV 4:2:2