MPC Video Renderer

[Angel]

господа, всем большое спасибо за ваши ответы!
простите что не слежу за форумом и задаю повторные вопросы. (которые уже были)
Evgeniy1990, насчёт навидии интересная инфа: я всегда был сторонником их продукции и сейчас у меня 1070 gtx.
---
насчёт сабов к сожалению я вам ничем помочь не могу, тк исползую XySubFilter.
раньше пока я сидел на встроенном рендере субтитров, но жизнь вынудила поставить внешний фильтр, тк анимешники народ не следующий стандартам написания сабов и зачастую их творения отображались во встроенном движке как минимум некорректно (я писал об этом пару раз на руборд в наш профильный топик).
в итоге устал бороться и просто поставил фильтр, 99% проблем с сабами исчезли.

вот и сейчас

Режим D3D11 медленнее выводит субтитры.

как пишет V0lt, на XySubFilter в директ 11 я этого никогда не замечал.

[V0lt]

Выложил MPCVideoRenderer-v0.4.2.1168. В этой сборке у меня для веб-камеры стало выдавать нормальные данные в статистике.

Добавлено: 2020-02-27 19:53:35

9. Dither под вопросом. Работает он, или нет

Работу дизеринга на типовом мониторе врядли можно увидеть.
Имхо, нужен большой телевизор с честной 8-битной (или лучше) матрицей, работающий в режиме "ПК", "Рабочий стол" или другом подобном, который минимизирует обработку картинки самим телевизором. Смотреть на нем надо видео с плавными градиентами (закаты там всякие или просто тестовые картинки). И вот в некоторых случаях, градиент с дизерингом будет плавнее, чем без него.


Добавлено: 2020-02-27 19:55:09

PS: Дизеринг не удаляет существующий бандинг.

[lexxx]

MPC Video Renderer v0.4.2.1166 (git-2020.02.26-4714f04) x64 (K-Lite_Codec_Pack_1540_Standard)
Windows 10, GTX660, показания в диспетчере задач

Загрузка GPU для неинтерлейсного видео:
DX11 Discard 28 - лучший режим
DX9 Discard 32
DX11 Flip 30
DX9 Flip 30

Загрузка GPU для интерлейсного видео:
DX11 Discard 46
DX9 Discard 50
DX11 Flip 43 - лучший режим
DX9 Flip 43 - лучший режим

Худшим режимом оказался режим по-умолчанию DX9 Discard, а лучший неоднозначный, но склоняюсь к любому Flip.
В DX11 при включении субтитров заметна пауза.

[V0lt]

lexxx
При замерах загрузки GPU всегда надо смотреть еще и частоту чипа.
Например: 40% при 600 МГц будут меньше нагружать видеокарту чем 30% при 1200 Мгц.

Добавлено: 2020-02-29 17:20:21

Сделал описание настроек MPC VR. В будущем будет дополняться.

[V0lt]

Я разобрался с проблемой отсутствия пропуска кадров и последующим рассинхроном видео и звука.

В "базовом рендерере" считается среднее время рендеринга. Это время потом учитывается при решении пропускать кадр или нет. В коде есть фильтр от случайных больших всплесков рендеринга. Например, из последовательности 5 6 5 110 5 7 будет проигнорировано значение 110. Если таких значений будет несколько подряд, то второе и последующее большие значения будут приняты. Например, в проследовательности 5 6 5 110 105 106 7 значение 110 будет проигнорировано, а 105 и 106 учтены.
В моем случае значения постоянно менялись с меньшего на большее. Получалась вот такая последовательность 5 125 6 127 5 126 5 128. Алгоритм игнорировал все большие значения (125 127 126 128) и оставались только малые (5 6 5 5). Рендерер думает, что работает быстро и пропускать кадры не нужно.

Обошел проблему в v0.4.2.1172 git-ea4eb9. Почему время рендеринга так сильно мотает мне непонятно.

[lexxx]

V0lt
Все на одной минимальной частоте. Когда увидел, как выстрелил DX11 Discard (интересно, почему это произошло), подумал, что вот и настало время переходить на DX11. Но т.к. на интерлейсном видео этого не происходит, пока остался на DX9 Flip.

[V0lt]

Aleksoid1978

Код Выделить Развернуть

+ SubRenderIntf.h
m_pSubCallBack -> bUseInMPCBEБыл простой рабочий код. Теперь костыли ради кривого кода в второнних плеерах? :|

[Aleksoid1978]

В том то и дело - что m_pSubCallBack не дает никакой гарантии. Свой то код(MPC-BE) мы знаем, в нашем коде уже есть вызовы Paint() -> ReDraw(). А как оно там в других программах - нет. Поэтому я и сделал так - и это правильно.

[V0lt]

Хмм... допустим. Тогда мне непонятно зачем для MPC-BE и других плееров разный код поддержки. Комментриев в коде по использованию bUseInMPCBE нет. Эта переменная просто меняет логику 3 функций. Я не понимаю, как такое поддерживать.

Добавлено: 2020-03-07 13:18:55

Например CMpcVideoRenderer::SetMediaType() в которой есть такой код:

Код Выделить Развернуть

if (!bUseInMPCBE) {
    Redraw();
}У меня нет ни одной идеи, зачем понадобился этот костыль именно в этой фукции.

[Aleksoid1978]

Чем мешает ?

Ну а по факту - честно говоря я даже не знаю зачем в CMpcVideoRenderer::SetMediaType() вызов принудительной отрисовки.

[V0lt]

Проблему с поворотом добавил в "Известные проблемы".

Нашел баг округления в расчетах. Суть в следующем. Имеем маленькую квадратную картинку (например, 18x18). Раскрываем окно на весь экран, слева и вправа картинки черные поля. Нажимаем Num9, и вместо равномерного увеличения, картинка некоторое время увеличивается только по ширине.

Добавлено: 2020-03-10 18:21:50

Радикально устранил ошибку округления в mpcvr_1180_fix_geometry_1 для режима DX9. В результате чего рендерер стал намного больше кушать при сильном зуме.

[MPCfan]

V0lt,
На паузе в статистике mpc-vr некоторые элементы реагируют на движение мышки в зоне видео-области в полно-экранном режиме > https://yadi.sk/i/Rm2fNSjiINoSlg Так должно быть?

[V0lt]

MPCfan
Да так и должно быть, т.к. рендерер перерисовает кадр и статистику.

Ранее статистика еще считала кадры при любой перерисовке, но это некоторым сильно не понравилось (типа "некрасиво") и данную фичу урезали.

[MPCfan]

V0lt,
Спасибо. Понял.

[Aleksoid1978]

На самом деле надо глянуть в коде MPC-BE - зачем при каждом движении мыши вызывается отрисовка.

P.S. Оптимизировал это дело, теперь не будет вызова перерисовки при простом движении мыши.