f(light)all

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

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

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

vivan wrote:
Нафиг тебе 4:2:2?

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

vivan wrote:
Лол, а что такого?

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

vivan wrote:
Банально медленнее.

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

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

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

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

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

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

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

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

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

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

И зря.

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

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

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

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

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

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

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

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

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

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

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

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

Адоб wrote:
- 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 wrote:
только там небось разница в битрейтах раз в 5

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

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

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

vivan wrote:
Выведенный v210 в mov

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

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

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

MI wrote:
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 wrote:
конвертирует 4:2:2 -> 4:2:0 через 16-битный RGB и преобразует в 16-битный intereaved формат

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

avs wrote:
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 wrote:
Получаем профит

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

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

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

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

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

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

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

Artofeel wrote:
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 wrote:
конвертить в 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 wrote:
и все равно, после в x264 будет:
resize [warning]: converting from yuyv422 to yuv422p
кстати, на сколько это плохо?

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

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

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

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

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

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

+

Artofeel wrote:
и выведен в 64 бита

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Artofeel wrote:
because, why not?

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

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

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

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

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

Artofeel wrote:
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 wrote:
а ты начал какую-то пургу гнать.

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

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

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

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

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

vivan wrote:
и что для 720p ты делал его ровно один

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

vivan wrote:
А зачем раздувать до 250 мб?

because, why not?

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

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

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

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

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

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

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

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

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

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

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

Artofeel wrote:
З О Ч Е М ?

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

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

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

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

Bill Ein wrote:
и psy-rd 1.00:0.50

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

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

Artofeel wrote:
и я кажется выяснил из-за чего раздувается битрейт это --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 wrote:
Это единственный способ запихнуть RGB в H.264. Икса это делает за тебя просто.

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

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

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

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

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

vivan wrote:
Тебе их не жалко?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Artofeel wrote:
о..это толсто...утонул!

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

vivan wrote:
а можно - той самой BGR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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