AMV News

[Bill Ein]

мда, Мадока Магыка 10bit в madVR и haali

[Aggressor]

Смотри: процесс lossy-кодирования подразумевает квантование кодируемой информации, а это приводит к относительным ошибкам (допуски квантования). Т.е. независимо от того, какой у тебя исходник, кодирование его 8-битным алгоритмом больше его изуродует, чем кодирование 10-битным алгоритмом. А ещё есть чисто математические допуски округления, особенно заметные на этапе просчёта компенсации движения, тут 10-бит тоже впереди из-за более высокой точности.

Edit: чатик. )

[Neko Baka]

trampler
конечно матрица P-IPS считается лучше чем матрица E-IPS но преимущество у матрицы E-IPS заключается в том что цвета у нее идут мягче чем у P-IPS ну это чисто мое мнение так как я сам пользуюсь наработе двумя компами и с разными мониторами который один на E-IPS и P-IPS, еще мониторы на матрице P-IPS они слишком долго разогреваются , а применять его можно к примеру в обработке фотографий когда цветовая передача важна, и глаза на них не так садятся чем на тойже матрице TN у которой цветопередача куда хуже и холоднее.)) но это кому как

[batareiko]

Neko Baka
это похоже на высказывания из серии "теплый ламповый звук"

[vivan]

Ух ты какая тема.

[FllearTM]

Настроил madVR, и правда лучше чем коре, цвета сочнее и плавнее.

[Aggressor]

VirtualTT
Это похоже на некалиброванные мониторы.

vivan
Получается, если качать рипы по разрешению монитора (FullHD), то проблема апскейла отпадает, и ffdshow уравнивается в правах с другими декодерами и всеми рендерами?

[vivan]

Если выводить в RGB24 - вроде бы да.
Только ffdshow цвет все равно похуже апскейлит (у него ж разрешение в два раза ниже) чем madVR, но это разница малозаметна.

[Aggressor]

Надо определиться, что MadVR в первую очередь рендерер, но имеет встроенный декодер для MPEG-2, VC-1 и h.264. Предлагаю для устранения недопониманий разделять эти два понятия.

[FllearTM]

Так как лучше всего то?
Связка MadVR + CoreAVC

Или связка MadVR + ffdshow

[Aggressor]

Как ни странно, но ffdshow более правильно выглядит.
А визуально что?

Edit: либо я не понимаю в этом OSD от MadVR.

[vivan]

это не ffdshow, это встроенный libavcodec.
При декодировании через ffdshow будет так:


А если говорить о встроенном в madVR libavcodec и CoreAVC - то разницы нет, они должны отдавать идентичный поток рендереру.
Так что остается разница в удобстве - мне на ноуте убодней кореавц, поскольку он на обычном 8 битном видео использует декодирование на видеокарте ("CUDA"), а на 10 - переключается на софт. Мб кореавц чуть побыстрей будет (они обещали всякие оптимизации), лень тестить.
А так, на десктопе с норм процом проще со встроенным в madVR декодером.

[Aggressor]

[FllearTM]

Aggressor
Визуально не на много отличается, только чуть насыщенней цвета при MadVR + CoreAVC, но это чисто если пялится в монитор в ожидание найти косяк чем хуже или лучше.

[Aggressor]

FllearTM
По идее должно быть одинаково, но может что-то недопилили чуток.

Я уже начал тестировать, завтра выдам результаты.

[trampler]

FllearTM, Aggressor, vivan , извините, мужики, что опять встреваю, два раза всё перечитал, что-то понял, но в основном не очень. Постараюсь структурировать бурный поток непонимая:

1. Если 10-битный алгоритм эффективнее на любой входной информации за счет точности, почему тогда не кодировать сразу 12-битным, или 16, или 100500-битным? В чём прикол? 10 — это некая равновесная константа для оптимального кодирования лосси-видео, и 12 будет хуже? Или дело в повышенной битности самой выходной картинки, и замечательно закодированные 100500 бит мониторы тупо не смогут правильно отобразить? Но ведь, как заметил vivan, 99% мониторов и 10 не могут отображать, а отображают те самые 8.

2. Если, тем не менее, именно 10-битное кодирование лучше, то почему всё это время кодировали 8-битным? Он был ошибкой, больше не нужен и скоро (после доработки декодеров/плееров/рендереров) отомрет за ненабностью как старый и неэффективный, и Симпл перейдет на новый? Или 10 бит это такой сложный ресурсоемкий алгоритм, что его только сейчас смогли разработать и оптимизировать для приемлемой скорости кодирования/декодирования?

3. Почему мы вообще называем битность конечного цвета битностью алгоритма? Как влияет глубина конечного цвета на точность математических операций в промежуточном этапе просчета компенсации движения? На вход поступает картинка с 8-битным цветом, она может с любой точностью обрабатываться дальше, главное — округлить цвета на выходе соответсвенно до 8 или 10 бит. Или я не понимаю сути лосси-кодеков, и всё внутри них пляшет от дискретности цвета?

4. Я могу понять, что за счет лишних 2 бит сама компрессия сможет быть проведена более эффективно, без битрейтожоркого дизеринга и т. д., но это же лишние 2 бита, что натурально +25% веса, неужели эффективность сжатия от них повышается на 30-50%?

Можете не отвечать, если я задрал вас своей тупостью :)

[vivan]

[zmaster]

Интересно было бы посмотреть на результаты теста декодеров, в частности, на Lav – по слухам, это самый быстрый 10-bit декодер (~10%). А для x64 - вообще единственный приемлемый вариант…

[vivan]

madVR 32 бит онли, так что x64 декодер нафиг не нужен. И CoreAVC тоже есть x64.
Но Lav Decoder умеет в P010 выводить, как и кореавц.
Тем не менее... (проц - i5-2410M)


В обоих случаях вывод был в p010 (остальные просто отрубил).

[Aggressor]

В общем, как оформить результаты подобных тестов — я не очень представляю, поэтому напишу словесами:
1. Размеры файлов при одинаковом crf отличаются меньше чем на 5% (чаще на 2-3% в пользу 10-битной версии).
2. Качество у 10-битного энкодера выше, бандинга меньше (я бы сказал, нового бандинга не добавляется вообще в процессе кодирования).
3. Скорость энкода у 10-битной версии в 2 (!) раза ниже при прочих равных.

А ещё провёл небольшой отсмотр коллекции клипов на предмет бандинга и сделал вывод, что он там весьма редкий гость (в том виде, в каком он бросается в глаза, он вообще отсутствует).
Разницы между декодерами ffdshow и MadVR не увидел совершенно, а вот разница между рендерерами EVR и MadVR видна даже на 8битном видео в оконном режиме, в пользу MadVR (заметно на том же бандинге). Правда, эту разницу всё равно надо искать с лупой.

Вместо выводов: новинка лучше по качеству на сложных сценах (заметно с лупой), но в 2 раза медленнее при энкоде. С учётом того, чем придётся пожертвовать при массовом переходе на 10бит (DXVA, аппаратные плееры, он-лайн просмотр), форсить переход сейчас не вижу смысла.

Зато заметил, что x264 уже почти нативно хавает uncompressed RGB. Вот эта вещь может дать немало профита во всех отношениях, в т.ч. как антибандинг.

[FllearTM]

Ну теперь сложнее придется создателям АМВ, я уже полностью перешел на 10 бит, теперь не только BD но и HDTV делаю в 10бит рипы. Так-же все остальные лучшие кодеры переходят на 10 бит. Вроде Ёсей тоже будет теперь делать рипы только в 10 бит, но думаю вес его рипов не изменится

[Aggressor]

Да, новый сезон радует и огорчает в этом плане одновременно. Радует тем, что почти всё аниме теперь доступно и в 10-бит наряду с 8-бит, а огорчает тем, что не все релизеры используют преимущества нового формата: некоторые просто подменили экзешники энкодера на 10-битные, у других вес релизов даже прилично увеличился, а качество ухудшилось (артефакты первичного сжатия в ТВ-рипах, которые раньше заблюривались, стали более заметны).

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

[Bill Ein]

Aggressor, т.е. для симпла достаточно подменить енкодер на 32bit 10bit-depth отсюда?

[Aggressor]

Да, этого будет достаточно. Но не забудь забэкапить тот билд энкодера, что идёт в комплекте.

[Bill Ein]

Сейчас попробую закодить анкомпресс "Снежных Волков" симплом в 10бит

[FllearTM]

Aggressor
Я после замены сразу все переделал, перепробовал новые настройки кодера, и вроде подобрал что-то нормальное. Пришлось сразу и фильтры тоже все пересмотреть, ибо по большей части раньше приходилось давить банду и после её давить ещё что-бы она не вылезла по новой. Теперь можно только чуток убрать банду, остальное делает кодер, и на выходе уже видео вообще без банды.
Да и теперь просто поднимать битрейт выше 2000 вообще не имеет смысла. сколько смотрел логи на 720p достаточно в пределах 1700 на бдрип. На денпу вообще 1400 за глаза хватает. На онгоинг в пределах 1200-1500 не более. Выше просто идет перерасход.

[Bill Ein]

Aggressor,
Слева на право
Uncompress avi (3,04 ГБ), deluxe 8bit (25,5 МБ), deluxe 10bit (24,3 МБ)

В 10bit встроен dither: pattern?

[Aggressor]

FllearTM
Я всегда косо посматривал на релизеров, которые ориентируются на битрейт. Времена, когда надо было втиснуть n серий на болванку, уже прошли, а каждая серия уникальна в плане прожорливости. Поэтому использование crf логичнее, хотя его значения тоже надо пересмотреть по сравнению с 8-битной версией. Скажем, если для БД-рипа в 8 бит хороший ориентир crf 16, то для 10-битного ~18. Вариант «битрейт - логи - битрейт-штрих - два прохода» уже давно не оправдывает себя.

Bill Ein
Мне кажется, что у тебя неправильный декодер. На моих тестовых опытах тетради в клеточку не получались.

[W_aZZa]

Aggressor
Немного не по теме, но раз уж заговорили о crf. А что будет есть сначала закодировать используя флаг crf, глянуть на полученный битрейт, а потом забомбить с этим битрейтом в 3 прохода? Разница будет? Всё-таки в несколько проходов ключевые кадры выбираются правильнее и битрейт расходуется более практично.

[FllearTM]

Aggressor
Так я и использую давно CRF, в 10 бит он вообще разницу теряет между тем как я раньше выбирал на 8 бит. Сейчас уже ниже 18 вообще не вариант для 720p, битрейт заоблачный, который нафиг не нужен.
На онгоинг вполне 20 хватает. Ну не знаю, нахера делать большой битрейт если он там нафиг не сдался, да по обычным логам видно что перебор чистой воды. Это просто гигантомания какая-то, от того что там перерасход качество ну не как не увеличится.