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

Artofeel:

так, бегло.

Оно видно.

Artofeel:

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

Ну вот, таки смог же вспомнить! А теперь расскажи мне в чем проблема вывести >8 бит.
И сочность битностью не определяется, лол.

Artofeel:

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

Еще одна - убитая симплой, а последняя - бесполезные 4:2:2.

Artofeel:

и вообще, чо хочу то и делаю :P

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

Artofeel:

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

Только png для фото!!1 Только flac для видео на ютубике!!1 Только... хм... чеж еще придумать... М, да, только ремуксы, ага!
yv12 придумали не просто так. И раздувание битрейта в 5 раз без заметной пользы это лишь подтверждает.

Artofeel:

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

не улучшить, а ухудшить, ты вообще читал что я писал? =_=
Суть в том, что всем пофиг. Поддержку RGB прикрутили лишь потому, что это просто было. Для пряморуких (и знающих что они делают) придумали YCgCo, для остальных - yv12.
4:2:2 при таком сорце использовать - тоже дурость. Прежде чем такое делать лучше посравнивал бы и сделал бы выводы, вместо следования каким-то рандомным идеалам.

Artofeel:

где!? О_О

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

Artofeel:

набросил..

мда -_-'

Artofeel:

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

еще раз - что?
Есть скрин с видео. В ргб. Ависинтом его в yv12, а madVRом его обратно в ргб.

Artofeel:

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

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

Artofeel:

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

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

Artofeel:

Такое годится на низком битрейте.

Пфф, лол.

BesrezeN:

у меня одного 251.61 Мб 1280x720@29.97fps в зеленом? даже нет возможности сравнить до и после х(

LAV Filters поставь, а именно видеодекодер. И отруби встроенный в плеер декодер.

Artofeel:

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

Получилось чистое гладкое унылое мыло. Чтож еще варпшарпа не набросил? Мыльцо бы стало чОтким и вышел бы полный комплект вырвиглаза.

Artofeel:

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

чо?

Artofeel:

понятия не имею, давай объясняй мне. Быстро, решительно.

Разница между квантайзерами люмы и хромы. Хуман вижуал систем (aka глаз) менее чувствительна к цвету, поэтому можно резать его разрешение, а также качество.
Только, вот, тут в качестве люмы у тебя выступает канал R (скорее всего), а хромы - G и B. В результате у них разный уровень качества. Мило, не правда ли?

Artofeel:

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

лолчто? Икс вполне себе 16-битные источники потребляет. А дизерит потом рендерер, что явно получше чем шум сжимать @ битрейт раздувать.

Artofeel:

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

1) А что из них превратило его в такое жуткое мыло? http://screenshotcomparison.com/comparison/22987

2) Один из них скрин с видео, второй - с скрипта, конвертящего в yv12 (и обратно madVRом). Разница очевидна, ага.
http://3.firepic.org/3/images/2013-05/10/yrjrwkf3o46z.png
http://3.firepic.org/3/images/2013-05/10/0xv58h94nmri.png

3) ты в курсе что такое chroma-qp-offset, зачем оно у тебя стоит в -4 и к чему оно приводит?

4) а чтож не скормить все это счастье 10битному иксу?

Единственный плюс ргб версии - что она не запорота как та, которая yv12 #спасибосимплезаэто

Artofeel:

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

да ну. Подумаешь какие-то гигов 7 в лосслессе.


В общем эффорт стремится к нулю и это печально, ожидал чего-нибудь эпичненького. Неуверенное 3. И то, это титры повлияли.

MooNi:

Где ж ты такое большое разрешение раздобыл? Я еще пару месяцев назад искала не нашла т.т

В сети есть только одно видео (с никонико) и это именно оно, а точнее апскейл с него.

MooNi:

О_О ФИГАСЕ!!!! Ну, тогда ты просто монстр, и я тебе 5 влеплю без угрызений совести, за того что было сделать такое качество. А может ты тогда вообще все овашки перелопатишь, м? Их там всего ничего, и коротюсенькие :3

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

Artofeel:

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

Только, вот, сорец - все тот же yv12, да еще и 640х360 (=> хрома 320x180).
И чеж не анкомпрессед тогда? Оно ж еще оригинальней?

Q: зачем качать rgb версию?
A: ради вот такой разницы: http://screenshotcomparison.com/comparison/22952 (пожалуй она тут больше всего заметна).


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

Лайфхак - при просмотре side-by-side без всяких спец плееров можно софкусироваться перед монитором и наслаждаться триде.

Правда через 10 секунд заболят глаза, а через пару минут можно сказать зрению "прощай".

too much banding

варпшарп жесток

Бедный аспект, за что его так

Bjakua,
декодер, и железо (если аппаратный)?
У меня даже на атишке все ок...

P.s. mkvextractGUI пишет что не поддерживает такие аттачи, пришлось использовать штатный mkvextract через консольку

А чего еще можно ожидать от битрейта в 175 кбит на 640х360?

Хз, я тут особых спойлеров не заметил...

Polsovatel,
перемотай на 25:08 и удивись