You are not logged in. Please login or register.
SmoothVideo Project → Posts by vivan
LAV
0.45 - 2012/01/28
New DXVA2 "copy back" decoder
и у ффд есть DXVA декодер
А разве он не чистый DXVA (без возврата кадра в оперативку) и в результате абсолютно бесполезен?
У него в ноуте GT 540M (кстати как и у меня).
Только у меня в ноуте СО фиговая (ну да, такое же железо запихнули в тонкий и легкий 13.3"), проц сбрасывает частоту до номинальной (а то и вообще 800 мгц) - поэтому и реальные результаты заметно ниже (на синтетических еще не успевает перегреться).
Есть подозрение что файл в кэше просто не с самого начала. Например когда переключали качество - успело часть в низком скачаться, проиграться, и 720p начало качаться не с начала.
Мб поэтому инфы о кабаке и GOP'ах нет - видимо они только в заголовке хранятся. Мб поэтому его начало так глючить с VFR.
И при чем тут перекодировка? Отсутвие инфы - это отсутсвие инфы, вот если бы там был CAVLC вместо кабака... То было очень странно.
UPD: Кстати еще одна мысль - gsst это какое-то число, которое характеризует начало файла относительно исходного на сервере (если он с начала - то там 0, если нет - то непонятно в чем измеряемая величина (точно не кадры, мб блоки...), а gstd - конец.
З.ы. too slow, да.
кстати, лично у меня, что в кэше, что скачанный с помощью аддона YouTube Downloader файлы полностью идентичны.
А как CUVID (CUDA Video Decoding API) должен на атишке работать? о_О
У хорриблов просто жуткие проблемы с частотой кадров - она там не просто кривая, она там реально переменная.
Куда то есть, но для декодирования видео "через куду" используется CUDA Video Decoding API. Это доступ к аппаратному декодеру (которого в g80 нет) через куду.
Собственно зарелизил: http://forum.doom9.org/showthread.php?p … ost1532825
http://forum.doom9.org/showpost.php?p=1 … tcount=186
0.16 сегодня он зарелизит, и с ней можно будет использовать QS (очевидно только там где он есть, т.е. как минимум Sandy Bridge) на системах с дискретными картами без всяких virtu.
Rimsky
Вполне, там тоже цифры близки.
более свежий код из x264 - со всякими AVX-ами
Bulldozer doesn't benefit at all from AVX: it already has built-in move elimination, making AVX unnecessary.*
*It still helps code cache efficiency by saving code size, but that's a tiny effect.
и
I have access to a 2x16 core Bulldozer server, plus AMD is mailing us a physical system.
Yes, there will be XOP optimizations. Yes, they will help, at least a % or 2.
но таки
Anandtech seems to have declared a "new version of x264" to be an "AVX-enabled version of x264", assuming that the only difference between the two is AVX support, and commenting based on that. I'm guessing they didn't quite realize that their "HD benchmark" is using a version that's 2 years old, whereas the version AMD gave them was recent.
Noweol
:facepalm: Да, не использовался. Особенно это на скрине не видно.
У меня ноут, и встроенную видяху нельзя отключить.
На десктопе это вообще неактуально, ибо на декодирование просто смехотворные ресурсы уходят.
Не, только софтово 
Но проц хотя бы вытягивает. И рендер она тоже не тянет, но дискретная тянет, правда только EVR...
Разницы по нагрузке на проц - нет, везде это максимум 5%. Вообще это сильно от плеера зависит, в том же сплеше она на пару процентов ниже.
Чем померять производителньость не знаю, но 1080p@60fps с 16 рефреймами играется идеально.
А свп у меня тут нет 
P.s. заодно профиль заполнил...
И правда похоже возвращает - как минимум madVR c ним работает.
http://2.firepic.org/2/images/2011-09/2 … 1cinar.png
И даже с 16 рефреймами вроде все ок, по крайней мере не тех местах где сплеш (ну и CoreAVC с DXVA и встроенный в мпц декодер) артифачил тут все хорошо.
При таких же настройках загнется, ибо 1080p - это в два раза больше чем 720p. А 60*2 несколько больше 100%.
"Уплавление" - это построение промежуточных кадров. Очевидно, что самый нормальный вариант - это строить по 4 дополнительных кадра (итого в 5 раз выше фпс) и выкинуть каждый второй (24 * 5/2=60, 24/1.001 * 5/2 = 60/1.001 ~ 59.94).
Таким образом из 60 кадров исходных - 12. Остальные 48 имеют хуже качество т.е. артефакты.
И, если что, это повтор каждого 1000 кадра, т.е. 1 повтор на 41,7 секунды для 23.976 или 16,7 секунд для 59.94. Это как бы сложно назвать "поддергиванием" и ровно для этого и существует реклок.
Для того, чтобы таким образом получить чистые 60 фпс - нужно построить в 1001 кадров больше, и из них выкинуть 1000. Тобишь 24/1.001 * 1001/400 = 60.
Таким образом получается, что из 60 кадров реальных будет только 0,06. Т.е. 1 кадр раз в 16,7 секунд. Круто, правда?
Вопрос - а при наличии двух видеокарт (ноут, интегрированная в ЦП + дискретная нвидия = оптимус) - как задействоввать дискретную графику?
В настройках выставил использование дискретной графики для svpmark.exe, avs2avi.exe, а также в качестве значения по умолчанию - все равно использует интелловскую...
Since sources of mvtool are available - avisynth is not needed. You can collect all in a single library, that would take YV12 frame and interpolate intermediate frames.
And I don't think that madshi can help (also he said he is really busy now) - since main problem is not in adding SVP to renderer, but in disengagement from avisynth. And after that it will be possible to do anything - MPC fork, or new renderer...
And why personally? You can just ask him at d9...
Атишки и без того не тянут декодирование 1080p@60 fps видео 
Даже 50 не тянут. Хотя убербюджетный нетбучный ION - тянет.
Но речь идет конечно не о декодировании.
Ну так по комментарию... Если речь идет о последних двух цифрах - то пофиг же
Хотя такое указано только у asd98 и smoke, у остальных указанные частоты близки к "распознаным".
А можно в таблице поправить частоты тем, кто в комментах их указал?
Rimsky
ATI Catalyst Application Profiles
SmoothVideo Project → Posts by vivan
Powered by PunBB, supported by Informer Technologies, Inc.
