f(light)all

А что, очень интересно получилось, интригующе.

Неплохой тизер(если его можно так назвать),теперь осталось только подождать выхода аниме.

блин, теперь ждать когда полнометражный фильм выйдет, Артофил прямо прорекламировал. ))
...и нафиг она в противогазе ходила...
а по амв-хе вообще что-то писать желание отпало, почитав коменты. Диспут продолжается не первую неделю, за сим и делалось, м? Номинация за атмосферность.

vivan написал(а):
Нафиг тебе 4:2:2?

а почему нет? все равно CPU пахать на декодинге, а на размер это не повлияло.

vivan написал(а):
Лол, а что такого?

да был бы hi depth imageReader хотяб...

vivan написал(а):
Банально медленнее.

медленнее!?
делаю отпут сиквенс -> ставлю "skip exist files", запускаю 4 копии aerender, 4х быстрее чем один AE.
АЕ упал? avi запорот, все сначала! С сиквенсом, спокойно пропускаю уже отрендрненный кадры.
Нужно перерендрить сценку? С avi, придется все заново рендрить. С сиквенсом, выделяю нужные файлы, удаляю, запускаю рендер. Отрендрится только то, чего нету.
Мне продолжить?

vivan написал(а):
Ну значит все градиенты уже были шумом избиты и были не градиентами в >8 битах

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

vivan написал(а):
Рендер идет в стольки битах, сколько у проекта, а потом

если отпут 8bpc, у меня же 16bpc рендер и 16bpc вывод в 64битный PNG

Artofeel написал(а):
так почему же не доставлять его в чистом виде, если есть возможность?

Потому что это дико неэффективно.

Artofeel написал(а):
mov? M O V ! ?
макинтошер в треде!
D O N O T W A N T ! ! !
avi c "V210 10-bit YUV" оутпутом, не то?
тащемто, тоже что и у тебя, с еретическим mov

Делай как хочешь, лишь проверяй что фигню не делаешь. Матрицу там, диапазон, и прочую фигню. А если и будет фигня, то синтом она элементарно правится без заметных последствий.

Artofeel написал(а):
no no no no no
только от этого, уже воротит...
убираем

И зря.

Artofeel написал(а):
получаем исходный 4:2:2 для х264, его и кодим

Нафиг тебе 4:2:2? Я понимаю если была бы туча CG, четких цветастых эффектах - тогда бы о 4:4:4 можно было задуматься (и то при прямых руках)... Но тут далеко не такой случай.

Artofeel написал(а):
хмм..
как я и думал, расплюнуть, Dither, avs4x264mod, патченный ffvideosource, "удивительный" stack16 формат...

Лол, а что такого? Не нравится - запили нативные 16 бит в асивинт. И заодно Dither под него перепиши :D Ну или vapoursynth.

Artofeel написал(а):
ну, тру 10 бит, и чо с ним делать? :D

Радоваться красивым градиентам. Если бы они были (:

Artofeel написал(а):
оууу...я даже не хочу начинать холивар на эту тему...устал.
разве что в двух словах:
банально юзабельнее.

Банально медленнее.

Artofeel написал(а):
хмм...картинка полученная таким образом, побитово совпадает с картинкой полученной imageReader'ом синта, соответственно, тогда в синте тоже без дихтеринга получилось. Ты видишь здесь няшный бадинг?

Ну значит все градиенты уже были шумом избиты и были не градиентами в >8 битах (:

Artofeel написал(а):
патамуша Glow, в АЕ, лучше работает в 16\32 битах
патамуша рендер в >8 битах как раз таки спасает от бандинга на сильно закомпоженных сценах или цк.
*под 64 ты надеюсь понимаешь, что это 16*4 (RGBA)

Рендер идет в стольки битах, сколько у проекта, а потом:

Адоб написал(а):
- After Effects introduces dithering to reduce banding any time the data passes through an 8bpc bottleneck. E.g., if you're outputting to an 8bpc format, After Effects will dither the colors in the rendering phase. You can use this factoid to force dithering earlier by applying an adjustment layer that does nothing but uses an 8bpc effect---such as the Arithmetic effect with the default settings.

vivan написал(а):
только там небось разница в битрейтах раз в 5

ну, это с новых версий, там разница в 2 раза всего.

vivan написал(а):
Ибо дисплей то ргб, и все форматы в конце концов на это рассчитаны.

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

vivan написал(а):
Выведенный v210 в mov

mov? M O V ! ?
макинтошер в треде!
D O N O T W A N T ! ! !

vivan написал(а):
Нет. Либо что-то ты делаешь не так

avi c "V210 10-bit YUV" оутпутом, не то?
тащемто, тоже что и у тебя, с еретическим mov

MI написал(а):
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 3mn 36s
Bit rate : 425 Mbps
Width : 768 pixels
Height : 432 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 5.36 GiB (100%)

только матрица не та..хотя на таком разрешении, даже та (может AE учитывает его(?))

vivan написал(а):
конвертирует 4:2:2 -> 4:2:0 через 16-битный RGB и преобразует в 16-битный intereaved формат

no no no no no
только от этого, уже воротит...
убираем

avs написал(а):
Dither_convert_yuv_to_rgb (lsb_in=true, output="rgb48y")
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b)

получаем исходный 4:2:2 для х264, его и кодим

vivan написал(а):
Получаем профит

хмм..
как я и думал, расплюнуть, Dither, avs4x264mod, патченный ffvideosource, "удивительный" stack16 формат...
энивай, спс
ну, тру 10 бит, и чо с ним делать? :D

vivan написал(а):
Чем он идеальнее банального lossless ргб в авишке?

оууу...я даже не хочу начинать холивар на эту тему...устал.
разве что в двух словах:
банально юзабельнее.

vivan написал(а):
АЕшкой же. Берешь новый проект, ставишь ему 8 бит в свойствах, кидаешь свои тифки, получаешь няшную бандоту.

хмм...картинка полученная таким образом, побитово совпадает с картинкой полученной imageReader'ом синта, соответственно, тогда в синте тоже без дихтеринга получилось. Ты видишь здесь няшный бадинг?
либо и АЕ, и синт, и VD, и даже xnView, юзают ordered дихтеринг...но даже при нем, должна же быть хоть какая то разница в вычислениях?

vivan написал(а):
нафига, при твоем 8-битном то энкоде?

патамуша Glow, в АЕ, лучше работает в 16\32 битах
патамуша рендер в >8 битах как раз таки спасает от бандинга на сильно закомпоженных сценах или цк.
*под 64 ты надеюсь понимаешь, что это 16*4 (RGBA)

Artofeel написал(а):
O K A Y
http://www.mediafire.com/?00lg98duytf7wya,h5l14b646jzzh8o,uyz6plm8unj1m72
http://www.mediafire.com/?mjlm94i9p89clox,r4hwwp9fw3brkog,fv06hr0ij3ilkls
только не надо ныть на счет того, что я показываю исходное YUV, без его красивого преобразования madvr рендером, обратно в RGB.

>png
>исходное YUV
Вообще-то это не исходное YUV, а YUV сконвертированное в RGB неизвестно чем. И это неизвестно что использоало Rec601 матрицу для этого. Небось это неизестно что было дабом...
Вот тебе исправленные версии (сконвертированы обратно в yv12 с использованием Rec601 матрицы, а затем в rgb с использованием Rec709):
http://3.firepic.org/3/images/2013-05/16/q5n74kg2ecpw.png
http://3.firepic.org/3/images/2013-05/16/quxg5139xskg.png
Разница есть, только там небось разница в битрейтах раз в 5, плюс тут уже не качество передачи деталей, а качество передачи артифактов.
YUV нельзя просто так взять и показать. Даже если возьмешь джипег (который YUV не только может использовать, но и нередко использует), или любой другой поддерживающий это формат. Ибо дисплей то ргб, и все форматы в конце концов на это рассчитаны.
Но вообще, конечно, можно. Взять ffmpeg и вывести в .yuv.

Artofeel написал(а):
конвертить в YUV, в AE? бррр...
AE юзает 601 матрицу, даже если поставить working space на HDTV 709

Нет. Либо что-то ты делаешь не так (хотя я слабо представляют что там можно сделать не так), либо у тебя какой-кривой AE.
Вот тебе пример:
Скрин из AE https://dl.dropboxusercontent.com/u/16254258/test/v210/AE.png
Выведенный v210 в mov https://dl.dropboxusercontent.com/u/16254258/test/v210/Comp%201.mov
Он же, открытый в плеере:
https://dl.dropboxusercontent.com/u/16254258/test/v210/709.png
https://dl.dropboxusercontent.com/u/16254258/test/v210/601.png
(угадай с 1 раза где правильно)
Берем скрипт https://dl.dropboxusercontent.com/u/16254258/test/v210/enc.avs
(открывает mov, конвертирует 4:2:2 -> 4:2:0 через 16-битный RGB и преобразует в 16-битный intereaved формат)
Кодируем иксой https://dl.dropboxusercontent.com/u/16254258/test/v210/x264.png
Получаем профит https://dl.dropboxusercontent.com/u/16254258/test/v210/enc.mp4
И скрин с профита https://dl.dropboxusercontent.com/u/16254258/test/v210/enc.png

Artofeel написал(а):
и все равно, после в x264 будет:
resize [warning]: converting from yuyv422 to yuv422p
кстати, на сколько это плохо?

Они отличаются только представлением в памяти.

Artofeel написал(а):
1. Сиквенс — идеальный формат для рендера.

Чем он идеальнее банального lossless ргб в авишке?

Artofeel написал(а):
ооо, вот тут пожалуйста по подробнее. Чем это ты собрался округлять?

АЕшкой же. Берешь новый проект, ставишь ему 8 бит в свойствах, кидаешь свои тифки, получаешь няшную бандоту. Только не спрашивай нафига так делать xD
Но в любом случае

Artofeel написал(а):
2. Потому что в АЕ больше не во что выводить >8 бит на канал.

+

Artofeel написал(а):
и выведен в 64 бита

нафига, при твоем 8-битном то энкоде?

Артик, как всегда, неподражаем!
всегда необычные работы
5

vivan написал(а):
Нормальный декодер ничего не ожидает и передает флаг range рендереру, который тот учитывает.

хмм..действительно работает..не знаю, почему у меня раньше не получалось.

vivan написал(а):
Только давай скрин, а не пустое бла-бла-бла вида "так лучше потому что лучше!!1".

O K A Y
http://www.mediafire.com/?00lg98duytf7wya,h5l14b646jzzh8o,uyz6plm8unj1m72
http://www.mediafire.com/?mjlm94i9p89clox,r4hwwp9fw3brkog,fv06hr0ij3ilkls
только не надо ныть на счет того, что я показываю исходное YUV, без его красивого преобразования madvr рендером, обратно в RGB.

vivan написал(а):
Попытка номер 2: я предлагаю выводить v210.

конвертить в YUV, в AE? бррр...
AE юзает 601 матрицу, даже если поставить working space на HDTV 709
и все равно, после в x264 будет:
resize [warning]: converting from yuyv422 to yuv422p
кстати, на сколько это плохо?

vivan написал(а):
Я даже не представляю нафига было выводить сиквенс, если все равно ты ргб кодил.

1. Сиквенс — идеальный формат для рендера.
2. Потому что в АЕ больше не во что выводить >8 бит на канал. (хотя подозреваю, что у QT есть что то, но я не хочу ставить это убожество +опять не та матрица при преобразовании..)

vivan написал(а):
Так зачем ты дизерил, вместо простого округления?

ооо, вот тут пожалуйста по подробнее. Чем это ты собрался округлять?

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

Manitou написал(а):
Читаю комменты и прям на глаза умнею))

--------------
по клипу: в целом работа понравилась, но пожалуй отрывок, когда бедная тян в ужасе вертела головой, я бы здесь хотела увидеть покороче. имхо, из-за его продолжительности наращивание напряжения сбивается. исходник заинтересовал, спс автору

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

Нормальный декодер ничего не ожидает и передает флаг range рендереру, который тот учитывает.

Artofeel написал(а):
а что сравнивать то? размер? артефакт в темном, нижнем, левом углу?

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

Artofeel написал(а):
мне достаточно того что, я получил (точнее сохранил) оригинальное RGB

Чем это "оригинальное RGB" объективно лучше yv24? Или даже yv12? Только давай скрин, а не пустое бла-бла-бла вида "так лучше потому что лучше!!1".

Artofeel написал(а):
ffms не читает сиквенс...
или ты предлагаешь через FFImageSource, 6500 строчек фигачить? :D

Попытка номер 2: я предлагаю выводить v210. Я даже не представляю нафига было выводить сиквенс, если все равно ты ргб кодил.

Artofeel написал(а):
так заморачиваться ради того, что не увидит никто, из-за того что моники у всех на 8бит..

Так зачем ты дизерил, вместо простого округления? Столько понтов многобитной обработкой, а на деле - вместо сохранения результата желание засыпать все несжимаемым шумком.

vivan написал(а):
Это от YUV вообще не зависит. RGB можно сделать и в TV-range, YUV - в PC. --input-range PC короче.

да, только вот декодер ожидает от YUV, tv диапазон, и куй ты его в этом переубедишь, и в итоге ты получишь серый на 16, вместо черного на 0...

vivan написал(а):
Т.е. ты решил сделать не как все, но при этом даже не удосужился сравнить с тем как было бы, если бы закодил как все?

а что сравнивать то? размер? артефакт в темном, нижнем, левом углу?
мне достаточно того что, я получил (точнее сохранил) оригинальное RGB

vivan написал(а):
нормально читается патченным ffms

ffms не читает сиквенс...
или ты предлагаешь через FFImageSource, 6500 строчек фигачить? :D

vivan написал(а):
если сможешь вывести (ну или чем-нибудь обработать чтобы получить) отдельно msb и lsb (старшую и младшую части 16 бит, т.е. каждая по 8), например в виде двух кадров или в stacked формате (2х высота, верхняя половина - msb кадра, нижняя - lsb)

ооддда..это звучит как расплюнуть...
так заморачиваться ради того, что не увидит никто, из-за того что моники у всех на 8бит..

Artofeel написал(а):
tv диапазоном, 16-235

1) Это от YUV вообще не зависит. RGB можно сделать и в TV-range, YUV - в PC. --input-range PC короче.
2) На 10 битах это приводит к реальной глубине цвета в 9.78 бит. Великая потеря. На 8 - 7.78, что не шибко дела меняет - все равно нужен шум, чтоб с бандингом бороться.

Artofeel написал(а):
because, why not?

Вот именно поэтому ты и не шаришь в кодировании видео (:

Artofeel написал(а):
это удел yuv фанбоев, пытающихся доказать что их божество, лучше жмется.

Oh, wow. Т.е. ты решил сделать не как все, но при этом даже не удосужился сравнить с тем как было бы, если бы закодил как все? Великий инноватор просто!

Artofeel написал(а):
Я, на такие очевидные вещи, время не тратил.

Это настолько очевидно, что просто неверно. Забавно как неверные вещи могут быь очевидны :D

Artofeel написал(а):
btw
закодить "тру" 10бит - не получится, для синта нужен imageReader который поддерживает вывод >8 бит на канал (в avi не получится сохранить 48\64 бита)
закодить 4:2:2 или 4:4:4 YUV с корректноый матрицей, тоже не получится...
остается только RGB :)

Ты ту ссылку на ависинт вики вообще читал? v210 (10-битный 4:2:2) нормально читается патченным ffms от SAPikachu. Это раз.
Два - если сможешь вывести (ну или чем-нибудь обработать чтобы получить) отдельно msb и lsb (старшую и младшую части 16 бит, т.е. каждая по 8), например в виде двух кадров или в stacked формате (2х высота, верхняя половина - msb кадра, нижняя - lsb), то дальше все тривиально (читай хелп к плагину Dither и что из себя представляет его rgb48y формат).

vivan написал(а):
а ты начал какую-то пургу гнать.

да? ..я подумал, что ты решил, что у меня YUV а не RGB. Рад что это не так.

vivan написал(а):
каким диапазоном, лол?

tv диапазоном, 16-235

vivan написал(а):
30 минут кодировалось. Ну я подумал что у тебя железо мощнее в два раза, а что, это не так что ли?

ну, у меня ~90 минут в фоне, это тоже, О БОГИ!, многа?

vivan написал(а):
и что для 720p ты делал его ровно один

хорошо, не буду.

vivan написал(а):
А зачем раздувать до 250 мб?

because, why not?

vivan написал(а):
так где был эксперимент сравнения yv12, yv24 и rgb версий, по результатам которого был сделан вывод о полной бесполезности последнего?

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

btw
закодить "тру" 10бит - не получится, для синта нужен imageReader который поддерживает вывод >8 бит на канал (в avi не получится сохранить 48\64 бита)
закодить 4:2:2 или 4:4:4 YUV с корректноый матрицей, тоже не получится...
остается только RGB :)

Artofeel написал(а):
Ну наконец то, ты это осознал..

Я? Я тебе в самом начале писал:

vivan написал(а):
Кодирование rgb - это костыль над 4:4:4 YUV и работает он просто - три канала (R, G, B) считаются за Y, Cb, Cr. А в поток записывается, что нужно использовать матрицу RGB (у которой коэффициенты равны 0 либо 1).

а ты начал какую-то пургу гнать.

Artofeel написал(а):
с подрезанным диапазоном, угугу

каким диапазоном, лол?

Artofeel написал(а):
да да, угу угу, а клипы клипать за минуту наверно, да? ЛОЛ

вообще на моем допотопном железе твое 720p ргб видео с твоими настройками (за исключением числа потоков, у тебя что, трехъядерник чтоль? оО) 30 минут кодировалось. Ну я подумал что у тебя железо мощнее в два раза, а что, это не так что ли?
Ну хорошо, пусть будет час. За твои 10 часов - это все еще 10 энкодов. Все равно достаточно для экспериментов, результатов которых не видно.
Только не говори что 10-15 часов - это время одного энкода, и что для 720p ты делал его ровно один

Artofeel написал(а):
З О Ч Е М ?

А зачем раздувать до 250 мб?
И да, я про полную с флаком, и про то, что при таком битрейте у нее качество будет не хуже твоего 250мб монстра.

Artofeel написал(а):
не понимал бы — не экспериментировал бы...

так где был эксперимент сравнения yv12, yv24 и rgb версий, по результатам которого был сделан вывод о полной бесполезности последнего? Я что-то такого не заметил.

Это амв обязательно прокомментирую. Оно оставило неизгладимое впечатление.

Bill Ein написал(а):
и psy-rd 1.00:0.50

тут была очепатка...я её обнаружил только после того как все отправил...
ну, первое это дефол х264, а второй должен был быть 0.05..

Клип сначала понравился, а порывшись инете понял что просто пересказ коротеньких спешлов. Б/о

Artofeel написал(а):
и я кажется выяснил из-за чего раздувается битрейт это --psy-rd
закодил без psy, получил 200 метров, причем повысил качество на 2 crf :)

Ещё бы, ведь ты поставил crf18. При таком crf отрицательный деблок и псай-рд несут только артефакты и в пустую повышают вес. Даже при CRF 17 псай рд имеет смысл ставить не более 0.4:0.0 А ты что загнул? deblock -2:-1 и psy-rd 1.00:0.50. Я второй параметр у псай-рд больше 0.25 ни в одном рипе не видел, на основании чего ты его так выгнул? Деблок может даже больше смысла поставить положительным будет. Хотя разбирайся сам, не буду больше тебя, как ты говоришь, смешить.

vivan написал(а):
Это единственный способ запихнуть RGB в H.264. Икса это делает за тебя просто.

Ну наконец то, ты это осознал..

vivan написал(а):
В любом другом 4:4:4 оно будет не менее оригинальным

с подрезанным диапазоном, угугу

vivan написал(а):
Если оценить время кодирования с твоими настройками минут в 15, то будет овер 20 энкодов. Что-то не виден эффект от этого.

да да, угу угу, а клипы клипать за минуту наверно, да? ЛОЛ
сразу видно, рипер :D
о чем мы вообще спорим...

vivan написал(а):
Тебе их не жалко?

нисколечки, нефиг было слушать старпёра.

vivan написал(а):
Вот показал бы ты мастер-класс по кодированию такого в 50 мб 10-битной иксой, был бы молодец.

З О Ч Е М ?
ну перекодил я 768x432 версию в обычные 10 бит, получил 18 МБ (вместе с аудио, того 28МБ)
И Ч О ? тут по соседству, клип с превью на 26 метров, на кой %уй мне так зажимать для фулки, какую-то сотню мегабайт?

vivan написал(а):
Понимал бы - хотя бы не носился так своим ргб... И настройки бы от балды не крутил.

не понимал бы — не экспериментировал бы...

понравилось =)

Читаю комменты и прям на глаза умнею))

По самому клипу ничего внятного сказать не могу - как-то мимо прошло, но исходник заинтересовал.

Artofeel написал(а):
аж даже стало интерестно, каким это образом?
Тебе не кажется, что это будет еще замороченее?

Замороченее? Это единственный способ запихнуть RGB в H.264. Икса это делает за тебя просто.

Artofeel написал(а):
Иными словами, у меня оригинальное изображение.

У тебя лосслесс? Нет. В любом другом 4:4:4 оно будет не менее оригинальным (и даже будет иметь лучшее качество при том же битрейте).

Artofeel написал(а):
ну может у тебя допотопный комп, я лично не жалуюсь на время кодирования, я гОраздо больше времени потратил на создание, что мне какие то 5-10 лишних часов на кодинг, пустяк.

5-10 часов? Если оценить время кодирования с твоими настройками минут в 15, то будет овер 20 энкодов. Что-то не виден эффект от этого.
И вообще, ты увеличиваешь энтропию. Я тут лоль вербую, чтобы они ценой своей жизни мир спасали... Тебе их не жалко? /人◕ __ ◕人\

Artofeel написал(а):
т.е. даже 100МБ обычной YUV, для тебя многА? нисмиши. у вас тут превью за 20 метров...

Для такого мыла 70 Мб в самый раз. Вот показал бы ты мастер-класс по кодированию такого в 50 мб 10-битной иксой, был бы молодец.

Artofeel написал(а):
о..это толсто...утонул!

Ну а что делать если это правда? Ты ж самых банальных принципов кодирования видео не понимаешь. Понимал бы - хотя бы не носился так своим ргб... И настройки бы от балды не крутил.

vivan написал(а):
а можно - той самой BGR

аж даже стало интерестно, каким это образом?
Тебе не кажется, что это будет еще замороченее?

vivan написал(а):
и обрати внимание на черточки, они там не просто так

ода, черточки..тогда у меня тоже R'G'B, угу

vivan написал(а):
Иными словами у тебя YUV 4:4:4 который без потерь (если бы оно лосслесс было) можно привести к исходному RGB.

Иными словами, у меня оригинальное изображение.

vivan написал(а):
типа +0.1% к сжатию ценой удвоения времени

ну может у тебя допотопный комп, я лично не жалуюсь на время кодирования, я гОраздо больше времени потратил на создание, что мне какие то 5-10 лишних часов на кодинг, пустяк.

vivan написал(а):
+200% к битрейту без визуальной разницы

т.е. даже 100МБ обычной YUV, для тебя многА? нисмиши. у вас тут превью за 20 метров...

vivan написал(а):
Ты просто в обработке и кодировании видео не шаришь, вот и все

о..это толсто...утонул!

btw, закодил без psy, с crf 17, получил 137 метров, still buthurt?

igor-aktay написал(а):
люди подскажите исходник аниме для этого клипа

а фиг его знает...если узнаешь дай мне знать! тож интересно посмотреть!!

Лол прикольно, атмосфера затягивает, ну и интересно) Мне доставило , сорс заинтриговал.

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

В YUV можно по-разному сконвертировать. Можно с использованием матрицы Rec709, а можно - той самой BGR. Собственно в последнем случае и будет побитово идентичный результат.

Artofeel написал(а):
т.е. там не то что пишет какая то программа-информатор или рендер

... или обеспечивает какой-то дурацкий формат

Artofeel написал(а):
например, кто то в вики написал

Правильно написал. В определенном случае 4:4:4 YUV можно называть R'G'B' (и обрати внимание на черточки, они там не просто так).

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

Иными словами у тебя YUV 4:4:4 который без потерь (если бы оно лосслесс было) можно привести к исходному RGB.

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

Ну они одинаково ужасны (:
выкрученный psy-rd это лишь треть проблемы.
Вместо выкручивания некоторых параметров для понта (типа +0.1% к сжатию ценой удвоения времени), а некоторых от балды (+200% к битрейту без визуальной разницы), лучше бы юзал адекватные настройки, сделал бы несколько энкодов, посравнивал и сделал бы выводы.

Artofeel написал(а):
Мы просто оперируем разными взглядами, ты не автор, ты ничего не создавал, тебе меня не понять, ты опираешься на какие-то ограничивающие стандарты кодирования видео-данных, не трать своё время, ты все равно не переубедишь меня. :)

Понтиями? Не автор? Ты просто в обработке и кодировании видео не шаришь, вот и все (:

люди подскажите исходник аниме для этого клипа
интересно посмотреть !!

Кусок исходника посинхренный чёрными вспышками на быстрых участках трека. Арт тестировал очередную техническую фишку? Замечательно. Рад, что НТР не стоит на месте. Исходник заинтересовал. А клипу двойка.)

Artofeel, ну ок, я просто думал Акита сделал креативу на тему.
А где кстате он сам?

mwDeus написал(а):
А чо тут такого было после того как я заснул?

да ничо толком, скучно становится в этом чатике

и я кажется выяснил из-за чего раздувается битрейт это --psy-rd
закодил без psy, получил 200 метров, причем повысил качество на 2 crf :)