Проблема:

Есть VMR9 в графе.
Если он не в Renderless mode, то всё ок.
Если он на win7, то всё ок.
Если он на XP, то проц грузит на 100%.
Комп неслабый, все плеера нормально отображают и БД на 1080р с загрузкой проца не более 60%.
Тут тебе на 100% загрузки проца, 50% потерянные кадры в VMR9, и это только на 720р...

Замечу, что НЕ Renderless работает нормально в GraphEdit.

Привожу примеры из кода кастомного презентатора-алокатора:

//чёткий метод презентации, да? 100% проца)
HRESULT STDMETHODCALLTYPE c_Texture_VMR9::PresentImage(DWORD_PTR dwUserID, VMR9PresentationInfo *lpPresInfo)
{
return S_OK;
}

//стандартная инициализации, ничего особенного, вроде как
HRESULT STDMETHODCALLTYPE c_Texture_VMR9::InitializeDevice(DWORD_PTR dwUserID, VMR9AllocationInfo *lpAllocInfo, DWORD *lpNumBuffers)
{
    m_pSurfaceWork = NULL;
    HRESULT Result = E_FAIL;
    if(lpNumBuffers == NULL)
        return E_POINTER;
    if(!mpVMRSurfaceAllocatorNotify || !m_pDirect3D || !mpDevice)
        return E_NOINTERFACE;

    Width = lpAllocInfo->dwWidth;
    Height = lpAllocInfo->dwHeight;
    if (d3dCaps.TextureCaps & D3DPTEXTURECAPS_POW2)
    {
        lpAllocInfo->dwWidth = 1;
        lpAllocInfo->dwHeight = 1;
        while(lpAllocInfo->dwWidth < Width )
            lpAllocInfo->dwWidth = lpAllocInfo->dwWidth << 1;
        while(lpAllocInfo->dwHeight < Height)
            lpAllocInfo->dwHeight = lpAllocInfo->dwHeight << 1;
    };
        //Тут я баловался и так и сяк- не выходит никак.
    //lpAllocInfo->Pool = D3DPOOL_DEFAULT;
    //lpAllocInfo->dwFlags = VMR9AllocFlag_OffscreenSurface;
    //lpAllocInfo->dwFlags |= VMR9AllocFlag_TextureSurface;
    
    //lpAllocInfo->Format = d3ddm.Format;
    UINT i;
    for (i = 0; i < mSurfaces.size(); ++i)
    {
        if (mSurfaces[i] != NULL)
        {
            mSurfaces[i]->Release();
            mSurfaces[i] = NULL;
        };
    };
    mSurfaces.resize(*lpNumBuffers);
    for (i = 0; i < mSurfaces.size(); ++i)
    {
        mSurfaces[i] = NULL;
    };
    Result = mpVMRSurfaceAllocatorNotify->AllocateSurfaceHelper(lpAllocInfo, lpNumBuffers, &(mSurfaces[0]));
    texWidth  = lpAllocInfo->dwWidth;
    texHeight = lpAllocInfo->dwHeight;

    return Result;
}

Замечу ещё, что пример из пакета "DX Extras" DX Extras 2004\Extras\DirectShow\Samples\C++\DirectShow\VMR9\VMR9Allocator\ без всяких моих вмешательств грузит проц на 100% всё равно.

Повторюсь, комп нормальный (НЕ Renderless — ок), тестировалось не на одной машине В итоге XP, Vista — проц 100%.
Всеми возможными путями было установлено, что это именно VMR9 Renderless грузит, от того и кадры пропускает.
Это какой-то полный бред...
Есть ли у кого какие мысли?
Мб, кто уже заводил VMR9 в Renderless?

Ау, кто-нибудь.
Наверняка кто-то уже заводил его в рендерлесс.

Здравствуйте, Аноним, Вы писали:

А>Ау, кто-нибудь.
А>Наверняка кто-то уже заводил его в рендерлесс.

Попробуй посмотреть исходники Media Player Classic HC, на его allocator-ы. Только предварительно убедись, что он не грузит в соотвествующем режиме проц на столько же

Здравствуйте, Аноним, Вы писали:

А>Замечу ещё, что пример из пакета "DX Extras" DX Extras 2004\Extras\DirectShow\Samples\C++\DirectShow\VMR9\VMR9Allocator\ без всяких моих вмешательств грузит проц на 100% всё равно.

Почему DX Extras аж 2004го года? Эти примеры есть в последнем Windows SDK. "Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\vmr9\vmr9allocator"

А>Мб, кто уже заводил VMR9 в Renderless?

Да. Заводили, и не раз. Всё отлично работает. ИМХО проблема не в VMR9, а в фильтре каком-то.
И ещё, вы случайно нигде не делаете такой вызов:

filterConfig->SetNumberOfStreams(1);

С этим тоже могут быть проблемы.

filterConfig->SetNumberOfStreams(1);

Нет, с этим проблем нету.
Если ставлю 1, то VMR переходит в Non-mixing mode и далее по его ещё нужно снабжать преференсами для режима смешивания.
Тут всё понятно.
----
Разобрался, почем проц 100%.
Всё дело в том, что у меня было два девайса Direct3DDecive9, один предлагал свои услуги VMR'у, а второй, собственно, рендерил на экран.
И второй, при наличии новых кадров, забирал себе кадр у первого девайса.
А всем же известно, что разные девайсы в соответствии с недоработками майкрософта не могут ничем между собой обмениваться.
То поэтому я юзал DXLoadSurfaceFromSurface, которая сначала танят память из видяхи в ОЗУ, потом обратно из ОЗУ в видяху, только в объект второго сурфейса, второго девайса.
Тупо да, копировать из видяхи в ОЗУ, а потом гнать обратно?
Собственно тут и был тормоз, на копировании из видяхи, в сторону видяхи скорость нормальная. (иначе они бы вообще никому не были нужны)
Была мысля создавать у первого девайса текстуру в D3DPOOL_SYSTEM, но VMR тупо выплёвывает такую текстуру, не зависимо в каком режиме он запущен.
Выплёвывает и всё, "не поддерживается, иди лесом."
Хотя я так бы смог уйти от лишних копирований и, что боле важно, от копирования памяти из видяхи.
Решил вопрос переходом на DirectX9Ex, где начал поддерживаться принцип шаринга ресурсов между девайсами.
(Само собой, ограничение на >=Vista)
(И сразу маленький ФАК:
Вопрос: "А нахрена тебе многопоточный рендеринг, клепай в один поток?"
Ответ : "Не катит, ибо тогда рендеринг общей сцены будет привязываться именно в fps видео. Это уже не говоря, если ты захочешь не одно видео на сцене. о_О Вот это да!"
Вопрос: "Тебе не надо больше одного видео, и fps 24 должно хватить, нэ?"
Ответ: "Нэ, сам знаю, что мне надо.")
---
Additional fun:
Хочу сделать буферизацию кадров, чтобы когда прошёл новый кадр, то поток видео-рендера не ждал забора его потока общего рендера, а снабжал VMR сурфейсом под новый кадр, чтобы тот уже начинал рисовать новый кадр.
Стандартная хотелка такая.
Так вот, у VMR'а есть поля для указания таких параметров, и заказа буффера сурфейсов нужного размера.
Но вот беда, ему абсолютно наплевать на эти переметры, тупо просит постоянно 1-й сурфейс.
Проинициализировал, к примеру, буффер из 3-х сурфейсов.
Дал ему первый, он его вырисовал.
Ты отдал его потоку2. VMR просит
Ты ему говоришь "Нет, он занят, приходи ещё"
Он снова ломится и снова просит сурфейс1.
И так пока не допросится.
Немёк на встроенную поддержку SurfacesChain есть, но ничерта не пашет. (Недоработка?)
Придётся писать свой chain или юзать EVR (привет, вин7!)
А если и в вин7 будет куча ограничений, то что?
И вообще, зачем интерфейсы DirectX при переходе с 9 на 10 так переколбасили?

Здравствуйте, Аноним, Вы писали:

А>Всё дело в том, что у меня было два девайса Direct3DDecive9, один предлагал свои услуги VMR'у, а второй, собственно, рендерил на экран.
А>Вопрос: "А нахрена тебе многопоточный рендеринг, клепай в один поток?"
А>Ответ : "Не катит, ибо тогда рендеринг общей сцены будет привязываться именно в fps видео. Это уже не говоря, если ты захочешь не одно видео на сцене. о_О Вот это да!"

У меня общий рендеринг не привязан к fps в видео, я обошёлся одним девайсом, и могу проигрывать произвольное количество видео на сцене. И всё это работает на Windows XP.
Платой стал флаг

D3DCREATE_MULTITHREADED

В моём случае падение производительности несущественное.

Здравствуйте, ka1eka, Вы писали:

K>Здравствуйте, Аноним, Вы писали:

А>>Всё дело в том, что у меня было два девайса Direct3DDecive9, один предлагал свои услуги VMR'у, а второй, собственно, рендерил на экран.
А>>Вопрос: "А нахрена тебе многопоточный рендеринг, клепай в один поток?"
А>>Ответ : "Не катит, ибо тогда рендеринг общей сцены будет привязываться именно в fps видео. Это уже не говоря, если ты захочешь не одно видео на сцене. о_О Вот это да!"

K>У меня общий рендеринг не привязан к fps в видео, я обошёлся одним девайсом, и могу проигрывать произвольное количество видео на сцене. И всё это работает на Windows XP.
K>Платой стал флаг

K>

K>D3DCREATE_MULTITHREADED
K>

K>В моём случае падение производительности несущественное.
Не-не-не.
Этот флаг тупо вешает критические секции на ВСЕ вызовы API DirectX.
В моем варианте это превращается в нереальное тормозилово.
Тем более "...не одно видео на сцене".
DirectX9 сам по себе немультипоточен. (очередная недоделка)

K>У меня общий рендеринг не привязан к fps в видео, я обошёлся одним девайсом, и могу проигрывать произвольное количество видео на сцене. И всё это работает на Windows XP.
K>Платой стал флаг
K>

K>D3DCREATE_MULTITHREADED
K>

K>В моём случае падение производительности несущественное.
Этого не может быть.
Какое видео запускается?
Сколько там фпсов?
Какие размеры кадров?
Битрейт?

Здравствуйте, Аноним, Вы писали:

А>Этот флаг тупо вешает критические секции на ВСЕ вызовы API DirectX.
А>В моем варианте это превращается в нереальное тормозилово.

Из документации:

D3DCREATE_MULTITHREADED
Indicates that the application requests Direct3D to be multithread safe. This makes a Direct3D thread take ownership of its global critical section more frequently, which can degrade performance. If an application processes window messages in one thread while making Direct3D API calls in another, the application must use this flag when creating the device. This window must also be destroyed before unloading d3d9.dll.

Критическая секция там одна. К тому же критическая секция — это почти бесплатная операция, если блокировки не случилось. В моём случае блокировка происходит только в момент рендеринга кадра VMR'ом, если одновременно сцена пытается отрендерить текстуру с текущим кадром. И то, мне кажется можно обойтись вообще без блокировок, но лень переписывать много лет работающий код.

Здравствуйте, Аноним, Вы писали:

А>Этого не может быть.
Потому что не может быть никогда?

А>Какое видео запускается?
А>Сколько там фпсов?
А>Какие размеры кадров?
А>Битрейт?

Только что запустил одновременное проигрывание 6 разных роликов такого вида:

Format : MPEG-4 Visual
Codec ID : MP42
Duration : 25s 0ms
Bit rate : 3 105 Kbps
Width : 800 pixels
Height : 600 pixels
Frame rate : 25.000 fps
Stream size : 9.25 MiB (100%)

Загрузка процессора 14% (i5-2300, GT440). Фрапс показывает ~800 fps в оконном режиме и ~850 в полноэкранном. Нечестно, конечно, на таком процессоре, но Atom 330 на встроенном интеловском видео легко справлялся с двумя такими роликами и кучей другой графики для остальной сцены с запасом.

K>Только что запустил одновременное проигрывание 6 разных роликов такого вида:
K>

K>Format : MPEG-4 Visual
K>Codec ID : MP42
K>Duration : 25s 0ms
K>Bit rate : 3 105 Kbps
K>Width : 800 pixels
K>Height : 600 pixels
K>Frame rate : 25.000 fps
K>Stream size : 9.25 MiB (100%)

K>Загрузка процессора 14% (i5-2300, GT440). Фрапс показывает ~800 fps в оконном режиме и ~850 в полноэкранном. Нечестно, конечно, на таком процессоре, но Atom 330 на встроенном интеловском видео легко справлялся с двумя такими роликами и кучей другой графики для остальной сцены с запасом.

Фигня это, неэффективно.
Мне нужна производительность сравнимая с обычными плеерами.
Кто вам сказал, что критическая секция там одна?
Пробовал я так, на мощной видяхе фурычит более-менее на 1-2 видео.
На слабом уже явно видны различия по сравнению с тем же MPC.
Но мне религия не позволяет разбрасываться временем и сидеть в критических секциях.
Хочу истинную многопоточность.

Даже с рендертаргетами тоже самое.
Девайсы тупо никак не могут взаимодействовать между собой по-нормальному.
Что мешает одному отрендерить кадр на текстуру, пока другой юзает первый левел текстуры, а потом флипнуть, по завершению рендера первого?
Кстати, с опенГЛ таких проблем нету
Наводит на интересные мысли, но у него производительность меньше.
Так что тоже засада. И есть опенГЛ — то это автоматический отказ от VMR и EVR.
Ок, подниму ещё раз вопрос:
Из каких таких соображений VMR не хочет рендерить на D3DPOOL_SYSTEMEM?

Здравствуйте, Аноним, Вы писали:

А>Кто вам сказал, что критическая секция там одна?

Документация. Во фрагменте, который я приводил, написано critical section, а не critical sections. А почему вы решили, что их там больше одной?

А>Из каких таких соображений VMR не хочет рендерить на D3DPOOL_SYSTEMEM?

Никто не может рендерить в D3DPOOL_SYSTEMEM, не только VMR. D3DPOOL_SYSTEMEM — это оперативная память. У видеокарты нет доступа к оперативной памяти.

Зачем вам рендерить в D3DPOOL_SYSTEMEM, если можно обойтись одним девайсом и вообще без копирования?

Здравствуйте, ka1eka, Вы писали:

K>Здравствуйте, Аноним, Вы писали:

А>>Кто вам сказал, что критическая секция там одна?

K>Документация. Во фрагменте, который я приводил, написано critical section, а не critical sections. А почему вы решили, что их там больше одной?
Неправильно сказал.
Я имел в виду, что одна, но кроект ВСЕ вызовы АПИ.
И рисование происходит всегда.
Один поток рендерит сцену,
Другой в это же время рендерит картинку.
И друг друга блочат. Тут даже чисто теоретически будут лаги.
Немного спасает вертикальная синхронизация, но это бред.

А>>Из каких таких соображений VMR не хочет рендерить на D3DPOOL_SYSTEMEM?
K>Никто не может рендерить в D3DPOOL_SYSTEMEM, не только VMR. D3DPOOL_SYSTEMEM — это оперативная память. У видеокарты нет доступа к оперативной памяти.
Действительно.
Толкьо на overlay urface ВМР может рендарить.

K>Зачем вам рендерить в D3DPOOL_SYSTEMEM...
Не хочу я рендерить в системную память, это я просто клацал.

K>...если можно обойтись одним девайсом и вообще без копирования?
Не обойтись, я не вижу способа.
Можете подробно обговорить алгоритм, учтя следующее:
Видео FullHD 1080р, 24.996fps, 4Gb.
Таких видев надо запускать одновременно 3 штуки.
Три MPC могут одновременно играть их с загрузкой проца на 40%.
Стало быть, задача не невозможна.
Необходимо всё это на одной DirectX9 сцене.

(У меня пока из вменяемых вариантов только вариант с DirectX9Ex)