Автор Тема: MPC Video Renderer  (Прочитано 72944 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Angel

  • Пользователь
  • **
  • Сообщений: 97
MPC Video Renderer
« Ответ #645 : 26 Февраль 2020, 14:17:36 »
господа, всем большое спасибо за ваши ответы!
простите что не слежу за форумом и задаю повторные вопросы. (которые уже были)
Evgeniy1990, насчёт навидии интересная инфа: я всегда был сторонником их продукции и сейчас у меня 1070 gtx.
---
насчёт сабов к сожалению я вам ничем помочь не могу, тк исползую XySubFilter.
раньше пока я сидел на встроенном рендере субтитров, но жизнь вынудила поставить внешний фильтр, тк анимешники народ не следующий стандартам написания сабов и зачастую их творения отображались во встроенном движке как минимум некорректно (я писал об этом пару раз на руборд в наш профильный топик).
в итоге устал бороться и просто поставил фильтр, 99% проблем с сабами исчезли.

вот и сейчас
Цитировать
Режим D3D11 медленнее выводит субтитры.
как пишет V0lt, на XySubFilter в директ 11 я этого никогда не замечал.

V0lt

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 1811
MPC Video Renderer
« Ответ #646 : 27 Февраль 2020, 16:55:09 »
Выложил MPCVideoRenderer-v0.4.2.1168. В этой сборке у меня для веб-камеры стало выдавать нормальные данные в статистике.

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

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


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

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

lexxx

  • Пользователь
  • **
  • Сообщений: 15
MPC Video Renderer
« Ответ #647 : 29 Февраль 2020, 09:32:06 »
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

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 1811
MPC Video Renderer
« Ответ #648 : 29 Февраль 2020, 14:20:21 »
lexxx
При замерах загрузки GPU всегда надо смотреть еще и частоту чипа.
Например: 40% при 600 МГц будут меньше нагружать видеокарту чем 30% при 1200 Мгц.

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

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

V0lt

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 1811
MPC Video Renderer
« Ответ #649 : 01 Март 2020, 05:30:00 »
Я разобрался с проблемой отсутствия пропуска кадров и последующим рассинхроном видео и звука.

В "базовом рендерере" считается среднее время рендеринга. Это время потом учитывается при решении пропускать кадр или нет. В коде есть фильтр от случайных больших всплесков рендеринга. Например, из последовательности 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

  • Пользователь
  • **
  • Сообщений: 15
MPC Video Renderer
« Ответ #650 : 01 Март 2020, 06:47:51 »
V0lt
Все на одной минимальной частоте. Когда увидел, как выстрелил DX11 Discard (интересно, почему это произошло), подумал, что вот и настало время переходить на DX11. Но т.к. на интерлейсном видео этого не происходит, пока остался на DX9 Flip.

V0lt

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 1811
MPC Video Renderer
« Ответ #651 : 05 Март 2020, 05:49:37 »
Aleksoid1978
+ SubRenderIntf.h
m_pSubCallBack -> bUseInMPCBE
Был простой рабочий код. Теперь костыли ради кривого кода в второнних плеерах? :|

Aleksoid1978

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 2208
MPC Video Renderer
« Ответ #652 : 05 Март 2020, 06:09:20 »
В том то и дело - что m_pSubCallBack не дает никакой гарантии. Свой то код(MPC-BE) мы знаем, в нашем коде уже есть вызовы Paint() -> ReDraw(). А как оно там в других программах - нет. Поэтому я и сделал так - и это правильно.
I7 2600K@4.2 / Asrock P67 Extreme 4 Gen 3 / Kingston HyperX 8Gb 1866 (4x2) Kit / GIGABYTE GTX 960 / BenQ EW2430 / LG 47LM620T / Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215

V0lt

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 1811
MPC Video Renderer
« Ответ #653 : 07 Март 2020, 10:18:55 »
Хмм... допустим. Тогда мне непонятно зачем для MPC-BE и других плееров разный код поддержки. Комментриев в коде по использованию bUseInMPCBE нет. Эта переменная просто меняет логику 3 функций. Я не понимаю, как такое поддерживать.

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

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

Aleksoid1978

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 2208
MPC Video Renderer
« Ответ #654 : 07 Март 2020, 12:29:33 »
Чем мешает ? :)

Ну а по факту - честно говоря я даже не знаю зачем в CMpcVideoRenderer::SetMediaType() вызов принудительной отрисовки.
I7 2600K@4.2 / Asrock P67 Extreme 4 Gen 3 / Kingston HyperX 8Gb 1866 (4x2) Kit / GIGABYTE GTX 960 / BenQ EW2430 / LG 47LM620T / Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215

V0lt

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 1811
MPC Video Renderer
« Ответ #655 : 10 Март 2020, 15:21:50 »
Проблему с поворотом добавил в "Известные проблемы".

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

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

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

MPCfan

  • Постоялец
  • ***
  • Сообщений: 129
MPC Video Renderer
« Ответ #656 : 14 Март 2020, 17:50:31 »
V0lt,
На паузе в статистике mpc-vr некоторые элементы реагируют на движение мышки в зоне видео-области в полно-экранном режиме > https://yadi.sk/i/Rm2fNSjiINoSlg Так должно быть?

V0lt

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 1811
MPC Video Renderer
« Ответ #657 : 14 Март 2020, 18:36:46 »
MPCfan
Да так и должно быть, т.к. рендерер перерисовает кадр и статистику.

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

MPCfan

  • Постоялец
  • ***
  • Сообщений: 129
MPC Video Renderer
« Ответ #658 : 14 Март 2020, 18:42:13 »
V0lt,
Спасибо. Понял.

Aleksoid1978

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 2208
MPC Video Renderer
« Ответ #659 : 15 Март 2020, 03:22:21 »
На самом деле надо глянуть в коде MPC-BE - зачем при каждом движении мыши вызывается отрисовка.

P.S. Оптимизировал это дело, теперь не будет вызова перерисовки при простом движении мыши.
I7 2600K@4.2 / Asrock P67 Extreme 4 Gen 3 / Kingston HyperX 8Gb 1866 (4x2) Kit / GIGABYTE GTX 960 / BenQ EW2430 / LG 47LM620T / Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215