Последние комментарии vivan

ZaRish написал(а):
Что со списком исходников? Обязательно регистрироваться?

Я думаю его просто еще не успели публичным сделать.

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.

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-битном то энкоде?

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

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

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

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

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

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

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

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

Artofeel написал(а):
так заморачиваться ради того, что не увидит никто, из-за того что моники у всех на 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 формат).

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 версий, по результатам которого был сделан вывод о полной бесполезности последнего? Я что-то такого не заметил.

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

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

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

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

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

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

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

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

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

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

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

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

mwDeus, зайди в настройки madVR, devices -> то, во что ты смотришь, properties и выставь там глубину в 6 бит. Получишь много сильного мелкого шумка.

А еще можнешь повайнить на других страничках, чтоб все в 10бит кодили.

mwDeus, залезь туда откуда вылез.

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

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

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

Потому, что 4:4:4 с использовазнием матрицы GBR эквивалентно обычному RGB. Это раздувает размер минимум в два раза, т.к. в 4:4:4 в два раза больше семплов, чем в 4:2:0. Но по сравнению с нормальным 4:2:0, где хрома - это цвет, а не хрен знает что, размер раздувается еще больше.
Если добавить к этому неадекватные настройки (и не смеши меня чем-то вроде "я хотел сохранить детали/шумок!!1")... Но мне лень эксперементировать чтобы выяснить чем там именно ты еще в 2 раза раздул битрейт.

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

Ох.
Во-первых тебе медиинфо пишет:

MI написал(а):
Color space : YUV
Chroma subsampling : 4:4:4

Во-вторых тебе madvr пишет:

madVR написал(а):
h264, 4:4:4, 8bit
matrix: GBR (says bitstream)

В-третих H.264 ничего, кроме YUV c 4:2:0/4:2:2/4:4:4 сабсемплингом не поддерживает. Читай описание профилей в спецификации ниже.
В-четвертых http://3.firepic.org/3/images/2013-05/11/kvny8wzu4r3e.png и http://3.firepic.org/3/images/2013-05/11/15uygoqmv62e.png из оф. спецификации (http://www.itu.int/rec/T-REC-H.264-201201-S/en)

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

При правильном инпуте (http://avisynth.org/mediawiki/High_bit-depth_Support_with_Avisynth) он будет кодировать что есть. Я гарантирую это. Ну или закодь --crf 0 и сравни вычитанием (10-битный инпут vs 10-битный энкод).

Artofeel написал(а):
алсо, что то я не слыхал о RGB на 10\10\10, там же можно только по 8 или 16 или 32

Т.е. 4:2:0 ргб тебя не удивляет?) Еще раз повторю, что RGB - это 4:4:4 YUV + матрица BGR. Ну т.е. если передать YV24 в 16-битном interleaved формате + --colormatrix BGR то наверно будет то, что ты ожидаешь. Но это я гарантировать не могу, ибо фигней такой не занимался... И в который раз повторю, что ничего, кроме раздутого в 5 раз битрейта ты этим не достигнешь.

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

Легко, конвертацией swscale занимается, который старый как...

UPD: все-таки пострадал фигней.
10 битное 4:4:4 вполне себе кодируется (достаточно --output-csp rgb, 10-битная версия в 8 бит ничего закодировать все равно не сможет), но LAV конвертирует его при декодировании в 8-битный RGB. Зато с YCgCo такого не происходит.

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

Я предлагаю дать иксу на вход 16 бит (можно и 10, разницы не будет) и закодить им в 10 (он больше не умеет, т.к. больше и смысла не имеет).
Мне тебе лекцию устроить, почему 10 таки имеет смысл?) Если кратко - зачем кодировать несжимаемый шум от дизеринга, если этот самый дизеренг может рендерер делать?
И если не страдать фигней (типа ргб) - то будет весить все те же 50 мб, если не меньше (ну и плюс мегабит на флак, или сколько он там весит).

Artofeel написал(а):
а разве не...

Нет. Это матрица, которая в поток прописывается. Там много чего можно прописать, например BGR - будет весело (видел когда-нибудь 4:2:0 RGB видео? Увидишь xD).

Artofeel написал(а):
еще одно доказательство, нах#й YUV

Просто не надо фигней страдать. x264 кодирует то, что ему на вход дают. Это энкодер, а не фигня "все в одном" (хотя некотрые страются его в нее превратить). Не нравится - вперед писать патчи.

Artofeel написал(а):
а я и вывел, ты вообще читал что я писал?

Да, читал. Помню там было

Artofeel написал(а):
Ты же предлагаешь 8 бит в магические 10 превратить.

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

Artofeel написал(а):
а определяется она кодингом, да?

Цветокором она определяется

Artofeel написал(а):
предпоследняя, последняя (внешняя) обычная YUV 4:2:0

... которая точно так же запорота.
Ргб версия http://5.firepic.org/5/images/2013-05/11/4oe2o7gv1rey.png
твоя yv12 http://5.firepic.org/5/images/2013-05/11/k6hnzj27slp4.png
скорректированная вручную http://5.firepic.org/5/images/2013-05/11/g4k6ohxtu84h.png
Знаешь почему симпл (а теперь и бака) запарывают видео при ргб сорце? Потому, что они полагаются на x264 для конвертирования его в yv12, а тот радостно использует для этого Rec601 матрицу. Почему ты, мастер синта, стопицотбитной обработки и дизеринга, делаешь так же - для меня остается загадкой...

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

Учитывая, что заметной человеку разницы (при использовании костыля, нивелирующего вышеуказанный косяк) с rgb версией нет, а весит она в 5 раз меньше - это был более разумный человек.