Коллеги,

Хочу немного обобщить ответ на вопросы типа "что будет с DirectShow, что нового в мультимедийных моделях" и т.д.

В Висте реализована программная модель нового поколения, которая называется Windows Media Foundation. В данный момент она поддерживает WMV (и остальные форматы Windows Media), MPEG2, и MP3. Оговорюсь, что во время разработки новой операционной системы нашей задачей было создать движок для Windows Media Player 11 и Windows Media Center. Мы не ставили цель завершить MF как полноценный API — во-многом, потому что такая завершенность требует откликов разработчиков, которые этот API используют. Однако, предполагается постепенный переход с DirectShow на MF. Мы понимаем, что для вас очень важна как можно более широкая поддержка форматов и операционных систем, но, я думаю, уже сейчас могут существовать сценарии подходящие для MF (в частности, когда DirectShow просто не справляется, как в случае с high definition).

Основные отличия новой модели:
— асинхронная модель, которая уменьшает число потоков, и, как следствие, число deadlocks;
— лучшая поддержка высокого разрешения (high definition);
— лучшая поддержка графических ускорителей (DirectX Video Acceleration 2);
— лучшая производительность;
— адаптация к новой графической среде десктопа (Aero);

Программная среда (Windows Media Foundation SDK) находится здесь:
http://msdn2.microsoft.com/en-us/library/ms694197.aspx

Форум разработчиков Макрософта по Media Foundation (ENGLISH):
http://forums.microsoft.com/msdn/showforum.aspx?forumid=387&siteid=1

Кстати, все остальные форумы, в которых участвуют разработчики MS, здесь:
http://forums.microsoft.com/MSDN/default.aspx?SiteID=1

Кроме того, в Висте разработана Windows Presentation Foundation (WPF, или бывший Avalon). Это программная среда для "сложных" приложений, своего рода попытка разработать модель в которой легко манипулировать самыми различными данными, от веба до аудио и видео и графики. В качестве средства такой интеграции предлагается XAML, разделяющий ресурсы и логику программы. SDK и даунлоады лежат здесь

http://msdn2.microsoft.com/en-us/netframework/aa663326.aspx

Существует еще одна разработка с похожим названием, WPF/e. Это мультиплатформенные презентации для веба. Хотя они частично построены на WPF, название "WPF/e" никак не расшифровывается и рассматривается просто как кодовое имя. WPF/e по сути отдельный продукт, и в данный момент находится в состоянии CPT (community preview). Но его сделают, скорее всего, быстрее, чем закончат MF и WPF, потому что он по объему намного меньше. Лежит здесь:

WPF/e
http://msdn2.microsoft.com/en-us/asp.net/bb187358.aspx
Там же есть ссылки на даунлоады

Средства разработки WPF(/e) — можно скачать и посмотреть как работает.
http://www.microsoft.com/products/expression/en/default.mspx

--------------------------------------
Я просто помещаю это сообщение как набор ссылок... Я не пытаюсь сказать, что нужно прекратить пользоваться DirectShow, VfW, и т.д. Просто указанные модели — то, над чем в настоящий момент работает Майкрософт и на что, так сказать, "возлагает надежды".

В связи с этим... не совсем в тему MF или WPF и т.д., но... Если хотите поучаствовать в формировании этих разработок под свои нужды, помещайте в качестве ответов на эту нитку желаемые сценарии. Скажем, то, что казалось довольно простым делом, но, столкнувшись с DirectShow, Вам пришлось придумывать и изощряться, как же это реализовать. Очень желательно, чтобы такие сценарии были не придуманными, а вполне реальными. Ну и, конечно, лучше без технических деталей (конкретных форматов, фирм, и так далее — нам интересны какие задачи решают разработчики с нашими платформами, и не что именно они делают).

Спасибо.

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

ДЕ>Коллеги,

ДЕ>Хочу немного обобщить ответ на вопросы типа "что будет с DirectShow, что нового в мультимедийных моделях" и т.д.

простой вопрос — Media Foundation будет только под Vista (как DirectX 10) или будет доступно под 2000/XP тоже?

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

S>Здравствуйте, Денис Евсеев, Вы писали:

ДЕ>>Коллеги,

ДЕ>>Хочу немного обобщить ответ на вопросы типа "что будет с DirectShow, что нового в мультимедийных моделях" и т.д.

S>простой вопрос — Media Foundation будет только под Vista (как DirectX 10) или будет доступно под 2000/XP тоже?

Да, только под Vista, как и DirectX 10. Авалон (WPF) планирует поддержку XP, а WPF/e — мультиплатформенный.

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

ДЕ>Здравствуйте, squid, Вы писали:

S>>Здравствуйте, Денис Евсеев, Вы писали:

ДЕ>>>Коллеги,

ДЕ>>>Хочу немного обобщить ответ на вопросы типа "что будет с DirectShow, что нового в мультимедийных моделях" и т.д.

S>>простой вопрос — Media Foundation будет только под Vista (как DirectX 10) или будет доступно под 2000/XP тоже?

ДЕ>Да, только под Vista, как и DirectX 10. Авалон (WPF) планирует поддержку XP, а WPF/e — мультиплатформенный.

насколько я понял из таблицы сравнения с DirectShow MF не поддерживает устройства видеозахвата и т.д. это как-бы временно или поддержка устройств ввода так и останеться только в DS в будующем?

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

S>Здравствуйте, Денис Евсеев, Вы писали:

ДЕ>>Здравствуйте, squid, Вы писали:

S>>>Здравствуйте, Денис Евсеев, Вы писали:

ДЕ>>>>Коллеги,

ДЕ>>>>Хочу немного обобщить ответ на вопросы типа "что будет с DirectShow, что нового в мультимедийных моделях" и т.д.

S>>>простой вопрос — Media Foundation будет только под Vista (как DirectX 10) или будет доступно под 2000/XP тоже?

ДЕ>>Да, только под Vista, как и DirectX 10. Авалон (WPF) планирует поддержку XP, а WPF/e — мультиплатформенный.

S> насколько я понял из таблицы сравнения с DirectShow MF не поддерживает устройства видеозахвата и т.д. это как-бы временно или поддержка устройств ввода так и останеться только в DS в будующем?

Временно. Устройства видеозахвата будут поддерживаться в MF.

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

ДЕ>Здравствуйте, squid, Вы писали:

S>>Здравствуйте, Денис Евсеев, Вы писали:

ДЕ>Временно. Устройства видеозахвата будут поддерживаться в MF.

спасибо.

Здравствуйте, Денис!

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

Спасибо!

PS. Если заходите связаться, то я доступен по e-mail

WR>PS. Если заходите связаться, то я доступен по e-mail

забыл: wonderu AT wonderu DOT com

Денис, спасибо за сообщение.

Некоторые вопросы:

1. Что имеется в виду под асинхронной моделью?

Мы считаем, что deadlocks –это лишь вопрос квалификации и понимания, как DirectShow устроен . В DS работают ровно столько потоков сколько нужно: 1) STA-поток для граф-менеджера (используется для коннекта); 2) MTA-поток для работы с самплами. Может быть добавлен еще один поток для Begin/EndFlush(), но достаточно редко, т.к. в основном эти команды вызываются источником (или сплиттером), а в этом случае без проблем может быть использован главный поток передачи самплов. Все остальные потоки — оптимизация или контроль выполнения. Как тут можно уменьшить?

2. Что имелось в виду под тем, что DirectShow не справляется с high definition? К каким компонентам DS это относится?

3. Лучшая поддержка графических ускорителей. Что имеется в виду? К каким компонентам это относится?

4. Производительность. Что имеется в виду? За счет чего это будет достигнуто? При правильном использовании у DirectShow нет проблем с производительностью. Т.е., если она и есть, то это проблема не DS, а конкретных компонентов, которые плохо написаны.

5. Адаптация к новой среде Aero. А какое это имеет какое-то отношение к программной модели?

Отвечая на ваш вопрос, основные практические проблемыDirectShow, с которыми мы сталкивались:

1. Неполная или некорректная документация.

2. Плохо реализованные базовые классы. Мы эту проблему решили, написав собственный SDK (как замену DirectShow Base Classes).

3. Перестройка графа в реальном времени. Теоретически возможно, но редко используется в виду того, что не поддерживается большинством фильтров. Решается использвоанием нескольких графов (наш MultiGraph или GMFBridge).

4. Автоматический рендеринг / Intelligent Connect – не всегда работает по причине проблем в третьих фильтрах. Плюс неприятная система выбора филтра, основанная на мерите, который задается производителем фильтра. Решение – избегать использования автоматичекого рендеринга и IC.

Получается, что недостатки DirectShow сводятся в основном к его сложности. В результате чего некоторые компоненты, в том числе и базовые классы MS, написаны некачественно. MS, по идее, вполне логично пытается сделать технологию более доступной и понятной. Для своих клиентов мы эту проблему сейчас решаем следующим образом – мы делаем над DirectShow-графом надстройку, которая имеет интерфейсы, доступные из любой среды разработки – будь то C#, Delphi, Basic, C++ Builder. Таким образом клиент получает компонент, решающий конкретную задачу, но абстрагированный от DirectShow.

С другой стороны, есть еще одна очевидная причина разработки Media Foundation ¬– это DRM.

Резюме. Сейчас мы, как разработчики, принципиальных проблем с DirectShow не испытываем. Относительно новой разработки, вы правильно написали, что создать полноценный API без откликов разработчиков – нельзя. Но ведь и мы не можем дать отклик до тех пор, пока не начнем технологию использовать. А мы начнем ее использовать только после того, как на нее начнут переходить наши клиенты. А как они могут на нее перейти, если пока она не решает ни одной из media tasks (audio/video capture, video editing, dvd playback, stream buffer, etc.)? Боюсь, что в результате получится, что к тому моменту, когда мы начнем с ней работать, она уже будет полностью спроектирована.


С уважением,
MediaLooks

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

AO>Мы считаем, что deadlocks –это лишь вопрос квалификации и понимания, как DirectShow устроен . В DS работают ровно столько потоков сколько нужно: 1) STA-поток для граф-менеджера (используется для коннекта); 2) MTA-поток для работы с самплами. Может быть добавлен еще один поток для Begin/EndFlush(), но достаточно редко, т.к. в основном эти команды вызываются источником (или сплиттером), а в этом случае без проблем может быть использован главный поток передачи самплов. Все остальные потоки — оптимизация или контроль выполнения. Как тут можно уменьшить?

+1

AO>2. Что имелось в виду под тем, что DirectShow не справляется с high definition? К каким компонентам DS это относится?

Наверно, к системе защиты HD контента точнее к отсутствию такой системы в DS

AO>3. Лучшая поддержка графических ускорителей. Что имеется в виду? К каким компонентам это относится?

Мне это тоже интересно. Можно ли будет использовать возможности расчета физики на видеокартах? Можно ли будет засовывать собственные шейдеры для обработки защищенного HD контента видеокартой?

AO>2. Плохо реализованные базовые классы.

+1 Словить дедлок как нечего делать, особенно пока не разберешься с потоками DS.

Здравствуйте, Андрей,

Большое спасибо за содержательный ответ. "некоторые компоненты, в том числе и базовые классы MS, написаны некачественно" — есть конкретные претензии в виде найденных *ошибок*?

Обзорная статья про DirectShow/MF лежит здесь
http://msdn2.microsoft.com/en-us/aa468614(msdn.10).aspx

По поводу производительности и т.д. отвечу попозже (сейчас некогда). дело не только в архитектуре MF, это вопрос спорный и даже внутри у нас есть разногласия — но также и в новых компонентах, таких как Enhanced Video Renderer. Я поговорил в несколькими ключевыми разработчиками DirectShow (они же делают MF) — хочу поговорить с performance team чтобы взять конкретные данные.

Спасибо!

Денис, добрый день,

Про ошибки в базовых классах – надо специально напрягать парней, чтобы они этот вопрос раскапывали. Я думаю сейчас это уже никому не нужно. Лучше скажите – куда писать в случае проблем или ошибок вWMF?

Будут ли ответы на остальные вопросы?

Здравствуйте, Андрей
Наконец появилось время ответить.

Одно предварительное замечание: я горячий поклонник DirectShow. Как бы ни было, эта архитектура используется много лет и очень успешно. Я сам принимаю участие в работе над DirectShow (в частности, пример MultiVMR9, который часто используют для работы с несколькими под-графами), так что убеждать, что это "достаточно хороший" API меня не нужно. Разумеется,"фильтры нужно уметь писать", но наш подход такой: мы смотрим на наиболее распрастраненные ошибки в написании фильтров и делаем выводы об архитектуре. Мы также стараемся смотреть, вынесет ли нас текущая архитектура в будущие сценарии. (Просто пример. Видео становится все больше и больше. Всякие мультиграфы — ну если у вас не совсем другая архитектура — это написание плагина-презентера рендерилки, чтобы поддерживал запросы от нескольких графов. Понятно, что написание такого "плагина" — это искусство возможного, способ обмануть DirectShow. Вопрос — не лучше ли иметь такую архитектуру, в которой множественные графы не проблема.

AO>Мы считаем, что deadlocks –это лишь вопрос квалификации и понимания, как DirectShow устроен

В-общем, и да и нет — согласен и не согласен. Конечно, если вот дан некий API, и писать под него нужно "вот так" — он работать будет. Однако если пользователи много лет наступают на одни и те же грабли, то возможно что-то не так с этим API. Может, я был не совсем точен по поводу числа потоков. На самом деле самая распрастраненная причина deadlocks в том, что event messages (EC_COMPLETE, EC_ABORT и т.д.) завязаны на message loop одного из окон приложения, чаще всего окна с видео (IMediaEventEx::SetNotifyWindow). Но при этом обработка производится из чьего-нибудь SendMessage, а это игра в рулетку, deadlock предотвратить *в общем случае* невозможно.

Проблема DirectShow — это распределенная модель обмена сэмплами. Тот же источник вызывает BeginFlush на присоединенный фильтр и тот чаще всего должен переслать комаду следующему фильтру и так далее. FilterGraph все это толком не контролирует. При этом DirectShow — открытая система, приложение может вставить какой угодно фильтр. И если там что-то не так, FilterGraph никогда не получит сообщение об ошибке (где-то в графе затор, а где — он не знает). Соответственно, нет даже возможности "обезвредить" застывший фильтр и перезапустить.

Другой неудобный момент DirectShow: единственный способ фильтрам договориться о чем-нибудь -- это заставить соединенные Pins выражать какой-нибудь свой интерфейс. (И именно в этом случае, для поддержки этого дополнительного сервиса, Pin чаще всего будет крутиться в своем собственном потоке — вот отсюда они и растут) Простой пример: mpeg декодеру нужны функции DXVA. Он берет соответствующие интерфейсы через соединенный pin видео рендерера, для этого он вынужден хитрым образом пометить свой выходной медиа-тип. Теперь, скажем, разработчик хочет встатить пиксел-шейдер между декодером и рендерилкой. Для этого его фильтр должен полностью поддерживать протокол договора о типах данных между декодером и рендерилкой.

(*) Еще один аргумент не в пользу DirectShow: большинству компаний-заказчиков (скажем, Adobe) граф не нужен. Им нужны отдельные фильтры (предпросмотр видео, например, или тот же декодер),а вот граф от DirectShow они бы с удовольствием пропустили. Однако архитектура требует чтобы все компоненты жили в среде DirectShow. Очень показательный пример -- компонента VidControl и фильтры Windows Media SDK: они делают "один фильтр" так чтобы он жил в DirectShow, а внутри этого фильтра делают свои собственный инфраструктуры (pipelines). Или вынуждены создавать фальшивые фильры (CrossBar, например. Это естественная часть Video Capture, однако единственный способ вынести функциональность на уровень приложения — разделить capture на исходный фильтр и этот "crossbar").

И по поводу множества потоков: я имел в виду под-проект Dexter (DirectShow Editing Services). Это мертвый проект: "не пошлО". И не пошлО именно по причине (*) — что каждый файл должен играться в отдельном графе и чтобы сделать "видео деку", нужно заинициализировать эти многие графы в самом начале. Архитектура слишком жесткая, чтобы переключать фильтры.

И, конечно, DRM. Неправильно предполагать, что наша позиция разнится с позицией других софтверных гигантов (можно догадаться, кого я имею в виду). Но раз мы вынуждены — то архитектура DirectShow этого не позволяет. В-общем, это не главная причана для возникновения MF. Главные причины я отметил выше.

AO>1. Что имеется в виду под асинхронной моделью?

MF — первая (и очень зеленая) попытка решить вышесказанные сложности. Общая идея — расслабить архитектуру: разбить ее на несколько уровней. Хотите готовые решения — будет что-то похожее на FilterGraph. Не хотите использовать граф — можно создать свою pipeline и просто использовть источники, рендерилки и преобразователи (IMFSource, IMFSink, и IMFTransform). Весь обмен данными *и сообщениями* вынести на "верхний уровень" (назовем его BitPump или IMFMediaProcessor). Вынести все сообщения в отдельный callback-интерфейс. Максимально отделить аллокаторы от фильтров. В результате получается асинхронная модель, потому что реализация фильтра — в большей части набор callback'ов (Начни делать xxx, когда закончишь — уведомь меня вот по этому интерфейсу IMFAsyncResult, или Выполнение xxx завершено, вот обработанный объект IUnknown).

AO>2. Что имелось в виду под тем, что DirectShow не справляется с high definition? К каким компонентам DS это относится?
AO>3. Лучшая поддержка графических ускорителей. Что имеется в виду? К каким компонентам это относится?

К декодерам, к рендерилке. MF не только архитектура, но и набор новых компонент. DXVA2.0, в частности. Который поддерживает лучший по ср. с DXVA1 hardware decoding. Новая рендерилка Enhanced Video Renderer (EVR) — лучшая поддержка 1080p и нового DVD формата при не бОльших (даже и меньших) нагрузках на CPU.

AO>4. Производительность. Что имеется в виду? За счет чего это будет достигнуто? При правильном использовании у DirectShow нет проблем с производительностью. Т.е., если она и есть, то это проблема не DS, а конкретных компонентов, которые плохо написаны.

Не скажите. Конечно, если какой-нибудь гений решит перекодировать видео сигнал из YUY2 в RGB32 в системной памяти и побайтово, никто ему не поможет. По нагрузке на CPU — MF и DirectShow примерно одинаковы. По требуемой памяти — MF немного жаднее (из-за асинхронности цепочка буферов на 1-2 длиннее). Однако в Windows существуют определенные правила приоритетезации (уф, какое слово) потоков, которые очень сильно мешают стабильности видео на компе, например. Так, окончание ввода-вывода поднимает приоретет до максимума, и в результате наш поток декодера вынужден "сморгнуть" видео, если какой то совершенно левый проц. В Windows Vista введен новый класс приоритетизации (кажется, он называется Multimedia Tread Scheduling?), который позволяет не блокировать мультимедийные потоки. Перенести эту модель в DirectShow нельзя, потому что там нет центрального блока обмена данными (какими в MF являются Working Queues и BitPump).

AO>5. Адаптация к новой среде Aero. А какое это имеет какое-то отношение к программной модели?

К программной модели не имеет, а к конкретной компоненте (EVR) имеет.

AO>2. Плохо реализованные базовые классы. Мы эту проблему решили, написав собственный SDK (как замену DirectShow Base Classes).

Как менеджер — менеджеру: это нормально. На самом деле, через меня проходят в-общем все баги связанные с базовыми классами. Так кроме чистки указателей и перевода строк в safe (все это было как часть security push в XP SP2) — багов там не было с 2002 года. Это нормально, что человек видит чужой код, пытается в нем разобраться — и через три дня приходит с идеей "все переписать". Если бюджет позволяет и результат будет более адаптирован к конкретным бизнес-задачам — пусть переписывают. Если хорошие программисты, хуже не будет. (Вот интеграция с Дельфи — замечательно, только это совершенно не наше дело, это дело третьих фирм -- Вашей, например) Это совершенно естественно и ожидаемо, мы ведь *публикуем* "базовые классы" именно для этого.

AO>3. Перестройка графа в реальном времени. Теоретически возможно, но редко используется в виду того, что не поддерживается большинством фильтров. Решается использвоанием нескольких графов (наш MultiGraph или GMFBridge).

AO>4. Автоматический рендеринг / Intelligent Connect – не всегда работает по причине проблем в третьих фильтрах. Плюс неприятная система выбора филтра, основанная на мерите, который задается производителем фильтра. Решение – избегать использования автоматичекого рендеринга и IC.

AO>Получается, что недостатки DirectShow сводятся в основном к его сложности. В результате чего некоторые компоненты, в том числе и базовые классы MS, написаны некачественно. MS, по идее, вполне логично пытается сделать технологию более доступной и понятной. Для своих клиентов мы эту проблему сейчас решаем следующим образом – мы делаем над DirectShow-графом надстройку, которая имеет интерфейсы, доступные из любой среды разработки – будь то C#, Delphi, Basic, C++ Builder. Таким образом клиент получает компонент, решающий конкретную задачу, но абстрагированный от DirectShow.

На это я уже ответил — и по поводу разбиения архитектуры на слои, расслабление архитектуры в целом.
Сделать "более понятной и доступной" — да, но это противоречит "сделать более гибкой". Сильно противоречит. Честно скажу, что писать на MF в том виде, как она сейчас есть, намно-о-ого сложнее чем на DirectShow. Потому что в том виде как есть она создана для "Эйнштейна".

Мы условно делим всех программистов-пользователей API на три категории: для краткости мы называем их Эйнштейн, Элвис, и Смертный. Эйнштейн — программист высокого уровня, работающий на детализации и мало использующий "готовые примеры". Элвис — примерно "покажите как сделать xxx, я скопирую в свою программу". Или Элвис — это проект, который требуем минимума ресурсов для решения совершенно другой бизнес-задачи ("вообще то это бухгалтерия, но я хочу в этом диалоге играть видео-файл с обращением директора с сотрудникам"). Смертный — чаще всего работает на visual basic и делает замечательные программы очень быстро с использованием готовых компонент. Так вот если мультимедийный API гибкий (работает в разных средах, способен реализовать свой собственный pipeline, и так далее) — то такому разработчику нужен доступ к самым экзотическим местам API, и простоты это совершенно не добаляет. Однако

AO> Относительно новой разработки, вы правильно написали, что создать полноценный API без откликов разработчиков – нельзя.

То, что скрыть от Элвиса и тем более Смертного, и что оставить доступным — очень непростое решение, и с первого раза угадать нельзя. Нужно дать возможность эйнштейнам покопаться, посмотреть какие программы они пишут и для чего, и потом абстрагировать API до уровня. "v= new Video("foo.avi"); v.Play();"

AO> А мы начнем ее использовать только после того, как на нее начнут переходить наши клиенты.

Совершенно согласен — я в самом первом посте оговорился что технология создана в первом приближениее, только заложены основы. Что MF используется для внутренних продуктов типа WMP и MediaCenter. Если Ваш бизнес — разработка надстроек над DirectShow, т.е. Ваши клиенты — программисты — то переходить на MF рано. Я, скорее, поместил пост обращаясь к разработчикам конечных продуктов, которые разрабатывают конечные решения (например, "система видоеслежения супермаркета") -- таким разработчикам переход на MF может быть интересен.

И, кстати, MF дает много возможностей для написания всякого рода "надстроек".

Надеюсь, более-менее ответил на Ваши вопросы. Я старался отвечать по существу и "то, что знаю". Спасибо.

Здравствуйте, Денис

Не подскажете, можно ли из MF plug-in'a во время плэйбэка получить IMFMediaSession или топологию, в которой плагин используется?

В DS это было легко, так как указатель на граф является членом класса CTransformFilter.

Спасибо.

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

А>Здравствуйте, Денис

А>Не подскажете, можно ли из MF plug-in'a во время плэйбэка получить IMFMediaSession или топологию, в которой плагин используется?

А>В DS это было легко, так как указатель на граф является членом класса CTransformFilter.

А>Спасибо.

Что Вы подразумеваете под MF Plug-in'ом? WMP OCX?

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

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

А>>Здравствуйте, Денис

А>>Не подскажете, можно ли из MF plug-in'a во время плэйбэка получить IMFMediaSession или топологию, в которой плагин используется?

А>>В DS это было легко, так как указатель на граф является членом класса CTransformFilter.

А>>Спасибо.

ДЕ>Что Вы подразумеваете под MF Plug-in'ом? WMP OCX?

я подразумемеваю Microsoft Foundation Transform, в котором реализуется видео или аудио декодер.

А, понял. В общем случае — нет, нельзя. Причем намеренно, чтобы фильтры друг с другом не разговаривали. Какой сценарий (другими словами -- что пытаетесь сделать), что требуется из MFT стучаться в тополоадер?

Денис.

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

А>А, понял. В общем случае — нет, нельзя. Причем намеренно, чтобы фильтры друг с другом не разговаривали. Какой сценарий (другими словами -- что пытаетесь сделать), что требуется из MFT стучаться в тополоадер?

А>Денис.

Дело в том, чно на момент построения топологии не известно, сможет ли рендер поддержать данные которые наш mft будет на него отдавать, и известно это станет только после того как топология будет построена и начнется playback. поэтому необходимо перенастроить рендер. Так как узнает об этом наш плаг-ин, то он и должен инициировать перестроение топологии.

в DirectShow это делается легко, так как Graph всегда доступен, а как это сделать в MF пока идей нет

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

ДЕ>в Windows существуют определенные правила приоритетезации потоков, которые очень сильно мешают стабильности видео на компе, например. Так, окончание ввода-вывода поднимает приоретет до максимума, и в результате наш поток декодера вынужден "сморгнуть" видео. В Windows Vista введен новый класс приоритетизации, который позволяет не блокировать мультимедийные потоки.

Основная причина — попытка решать задачи, требующие hard real-time, на ядре, изначально на это не рассчитанном. "Хитрая" приоретизация — следствие этого, "костыль", призванный немного облегчить положение. Как я понял, в Висте решили добавить новых костылей, вместо того, чтобы расшить основное узкое место.