%username% wrote:

OpenCL от одной версии драйверов с другими не работает!

Спасибо, стандартные драйвера (более новые чем в том тесте (выше) напомню 1080p) галочка активизируется без проблем.
Как раз появилась идея использовать с новейшими драйверами старый opencl -  но раз уж вы написали так... то наверно не буду пробовать...

Увы, в реальном времени 720p с оптимальными настройками good не потянет.

А если смотреть по таблице результатов (я отсылал и hd тест)

Так какие выводы можно сделать относительно измерений? (получились довольно разные показатели производительности видеокарты, но как их правильно интерпретировать? чем больше показатель,тем лучше?

Test summary драйвер NVIDIA    8.16.11.88.22 (галочка аппаратного ускорения неактивна - поэтому немогу отправить результат) *Насколько помню - выставлял в настройках  теста 1080P а не 720
-----------------------
  Date: 2012-10-08T11:12:16
  CPU:  Intel Core i3 M 350 @2261 MHz [4 threads]
  GPU:  NVIDIA GeForce GT 335M [ver.N/A]
  Mode: HD + CPU [6 threads]

Overall scores
-----------------------
  Synthetic CPU:                  MC556
  Real-life:                      HC1036

Details: synthetic
-----------------------
  CPU: compose (single-threaded): 275
  CPU: compose (multi-threaded):  655
  CPU: search (single-threaded):  206
  CPU: search (multi-threaded):   484

Details: real-life /HD
-----------------------
  decode video:                   8.93x (214.4 fps)
  48 fps - vectors search:        0.72x (34.4 fps)
  60 fps - frame composition:     0.84x (50.3 fps)
  48 fps - [SVP] fastest:         3.50x (168.1 fps)
  48 fps - [SVP] simple 1:        1.71x (82.1 fps)
  60 fps - [SVP] good:            0.81x (48.8 fps)
  60 fps - [SVP] high:            0.54x (32.3 fps)
  60 fps - [SVP] highest:         0.31x (18.6 fps)
  72 fps - [SVP] simple 2:        1.52x (109.7 fps)

%username% wrote:

konstanitinqq
Повторюсь: кэш уже используется. И не один, а несколько.

Повторимся

Но не в такое размере, как хотелось бы, к тому же, я не уверен , точнее я вообще не уверен в том, что он способен сделать видео воспроизведение более равномерным - в индексе производительности SVP видны провалы (зависит от сцен и производительности системы).
Или вы мне о чем то другом пишите?

Вернемся же к проблемам производительности видео?
Наверное вы и сами это замечали, что график SVP производительности не везде одинаков, и в некоторых сценах система не справляется с обработкой, для того чтобы этого избежать я предлагаю использовать буфер потока,как писалось выше:

1920*1080*12*60/8/1024^2 = 177 МБ/c

Вот что написал нам один из участников форума, даже если исходить из этого, это же намного повысит качество воспроизведения? (Например в местах посложней, буфер будет опустошаться а в более легких - заполняться)

У меня win7 Gt335m (с драйверами под квадру видимо не вышло получить достаточно хорошоую оценку), и проц i3.
http://www.svp-team.com/svpmark/results.html
Что можете сказать по поводу производительности\ настроек

А также ваши комментарии на тему: Что в видюхе нужно разогнать, чтобы получить прирост производительности SVP ( memory shaders Gpu)?
Ну там в результатах есть 1 тест с разогнанной видяхой GPU 450-623 Memory 790-1012 Shader 1080-1458

у меня "дергается" - тоже хочу исправить... (тему создал http://www.svp-team.com/forum/viewtopic.php?id=300)

%username% wrote:

konstanitinqq
http://www.svp-team.com/forum/misc.php?item=1819

Спасибо, но мне больше нравится когда все расписано, и объяснено "на пальцах" - К сожалению данный пресет не даст мне плавного воспроизведения на FHD, т.к. проц не вытянет (1080p), (вот незнаю в чем дело, но установка 2x (умножение кадров) и 2m (каждый кадр по 2 раза) сильно разгружают процессор (i3) и дают приемлемый индекс производительности SVP)/ Поэтому данный профиль смогу использовать только для изготовления файла для последующего просмотра, но все равно спасибо за попытку помочь (похоже на медвежью услугу, простите, если обидел)

vivan wrote:

konstanitinqq
Что если сохранять этот результат как я уже писал, во время просмотра, чтобы проигрыватель не взаимодействовал напрямую с SVP, а читал создающийся файл (кэш) уже готовый к воспроизведению на подобии youtubeской системы ?
1920*1080*12*60/8/1024^2 = 177 МБ/c. Одновременно на чтение и на запись. Реально только на SSD, и то если система его больше трогать не будет.
А также нужны соответствующие объемы. Например если хотите забуфиризировать полфильма - то готовьте 500Гб свободного места. И я еще молчу про износ SSD...

А скоростное сжатие? Что вообще никак?

Что то я подумал - 177Мб.секунду для моих 3-х гигов оперативки примерно 15 секунд буфера, что имеет смысл делать, если видео будет успевать буферизоваться -так что я уже хочу, разработчики, как вам идея?

%username% wrote:

konstanitinqq
1. Проблема плавности онимэ решена, ссылку дал. Проблема с онимэ в том что технически 23.976-25.000 кадр/с, но рисовка на 10-15 кадр/с
2. Полный буфер - перекодирование всего файла уже с 60 к/с. Воспроизводится намного легче чем уплавнение на лету.

Может быть дадите ссылку на русский гайд где описана проблема и решение? Со стороны разработчиков я как понял проблема не решена на уровне внедрения исправления в программ.(в виде пресета или еще чего). Если нет, то где гайды?

Тогда приведу другой пример - вы советовали для плавного воспроизведения сохранять результат?
Что если сохранять этот результат как я уже писал, во время просмотра, чтобы проигрыватель не взаимодействовал напрямую с SVP, а читал создающийся файл (кэш) уже готовый к воспроизведению на подобии youtubeской системы ?
Как если бы мы пытались посмотреть скачивающийся на торрентах фильм (недокачавшийся).

MAG79 wrote:

%username%
а если перекодировать?
Тогда не отключать. Именно эти моменты и надо учесть. Проверить и отладить их работу.

Если честно, я думаю что максимум что плохого случиться может от "клина" так это потеря данных в следствии незаконченности записи из за BSOD.
В будующем вам ведь не трудно сделать так, чтобы при запуске воспроизведения создавался кэш на диске (и\или в ОЗУ) - я уверен что это повысит производительность и качество работы SVP - Разве эта программа призвана не повысить качество источника?

%username% wrote:

Благородный дон уже прочитал девочку вики?

Мне кажется там не об моей проблеме ( разная частота кадров источника и рисовки)

MAG79 wrote:

konstanitinqq
Винт использовать для буфера нет смысла - очень медленный. Тут уж лучше сохранить весь пересчитанный фильм, а после смотреть его с диска.

Насчет движений в аниме (именно этот файл я еще не смотрел), вероятно они прорисованы не в каждом кадре, а через кадр или через два.
Тогда такие кадры можно предварительно обрабатывать как дропы, восстанавливая (додумывая) движения на кадрах, где оно не было прорисовано.
Подробнее см. Замена выпавших кадров (drop'ов) и SVP

Я имел ввиду сохранять обработанный(готовый) поток в оперативную память, и записывать на диск, если для плавного воспроизведения этого не достаточно - т.е. организовать более "профессиональную" работу с буфером, чтобы он сам формировался (буферизовался) после начала воспроизведения видео, так чтобы оно не прерывалось на буферизацию.

Я думаю вы поняли что я имел ввиду в общем анимацию, может для неё есть стандарты, чтобы вписать в следующую сборку новоиспеченный пресет по стандартам "аниме"? (Если немного разновидностей "дропов"(в этом случае под "дропами" подразумеваю уменьшенную частоту кадров по сравнению с частотой общего видеоряда) может их быстро можно классифицировать и собрать в "пресет", или же все так сложно что в основную сборку SVP эти наработки не войдут (по причине сложности и недоделанности) ?

Может быть есть уже это все, но в каком то другом (недоработанном возможно) проекте?


Скажите, то что я поставил в экспертном виде значения которые заполняют на максимум синенькие полоски - это даст мне лучшее качество? (Ежели не так, то какие настройки дадут мне наилучший результат?)

если честно, я даже не знаю что делает этот шейдер - поставил на максимум - в ожидании получить лучшее качество.

Насчет файла, и этот тоже (кстати я его и качал ), но дело в том чтобы внести эти изменения в будущую версию, доработав её. Цель, суть проблемы ясна?

В fHD 2m +2x поскольку самый щадящий процессор режим, а остальное можно побольше выкрутить )
Да, но название темы оптимальный профиль )

Для буферизации переделанного материала в режиме реального времени, наверное понадобится нетребовательный (к цпу) упаковщик - ну это наверное вы и сами знаете)

Сам я осознаю то, что для выравнивания частоты кадров движений и файла в целом(23.976fps), нужно для начала определиться с частотой кадров движений (анимации),и исходя из альфа версии готовой программы просчитать, а стоит ли оно того, чтобы начинать делать этот проект.(Дело не только в технической реализации, дело в том, понравится ли готовый результат, и будут ли эти усилия полезными? Что касается буферности - думаю это вопрос времени, например в кристале(плеере) уже осуществлен проект буферизации, я же предполагаю использовать вместе с SVP - MPC (он как то opensource'ней) )

Скачайте (если нету - вот это From Up On Poppy Hill (2011), например)- и включите самые самые настройки SVP.Заметили что нибудь? Что?

Хоть у меня fullHD не тянет даже на нормальных (делаю промежуточных кадров 2m и частоту кадров 2x) - Можно ли сделать что то на подобии прогрузки на youtube - у кого слабее аппаратная часть, просто ждет пока достаточно прогрузится и смотрит как обладатели крутых систем. (Думаю это повысит *общую плавность воспроизведения (*svp индекс разве не за неё отвечает?), и как следствие, общее качество просмотра).Идея такая чтобы использовать оперативную память как буфер 1 степени, и жесткий диск как буфер второй степени (для обладателей больших обьемов оперативки можно, думаю даже без своп файла на жестком диске - если часть видео потока будет буферизуется для последующего просмотра, так, чтобы видео не приостанавливалось, а просмотренное - удаляться из памяти). Опять же большие обьемы ОЗУ доступны на x64 win-х.

Вернемся к нашему аниме - наверное вы заметили что зумы\панорамирование проходят без проблем, а вот с плавностью самих движений(руками ногами) можно что то поделать?