Проблема GMFBridge при поиске исходного графика

Я пытаюсь использовать GMFBridge для переключения между несколькими графами потокового буфера, и у меня, похоже, две проблемы.

Вот схема графиков: http://massivefailure.net/dshowgraphsalt.jpg

  1. VMR на исходном графе моста, подключенном к графу рендеринга моста, очень прерывистый — новый кадр отображается каждые 4-5 секунд.

  2. Если я ищу исходный граф моста, который подключен к графу рендеринга моста, то весь вывод (VMR в подключенном исходном мосте и графах рендеринга, а также вывод на внешнем рендерере) останавливается примерно на минуту. Как только он возобновится, изменчивость от проблемы № 1 исчезнет.

Я пробовал отключать и останавливать график рендеринга моста перед поиском, повторно подключать и запускать его после поиска, но у меня все еще есть проблемы с зависанием или VMR на подключенном исходном графике моста, отображающем кадр примерно каждые 10 секунд.

Какая-то неважная проблема:

У меня были умные тройники там, где были бесконечные тройники, с VMR, подключенными к контактам предварительного просмотра, но после поиска они воспроизводились в 1,5-2 раза быстрее, чем обычно, пока не догнали прямой эфир. Есть ли разумный способ исправить это, чтобы я мог вернуться к смарт-ти?


c# directshow
person Community    schedule 17.09.2009    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Мост регулирует временные метки на образцах, поступающих в граф рендеринга, поскольку время потока на двух графах не совпадает. Однако фильтр inftee отправляет одну и ту же выборку на оба своих выхода. Таким образом, VMR в исходном графе (иногда) будет запрашиваться для рендеринга образцов, временные метки которых были скорректированы в графе рендеринга. Прерывистое воспроизведение, которое вы видите, является результатом того, что VMR безуспешно пытается наверстать упущенное.

Вам нужно скопировать данные или, по крайней мере, скопировать метаданные, чтобы измененные временные метки не отображались в исходном графике. Самый простой способ сделать это с несжатыми видеоданными — вставить преобразование копирования, такое как преобразователь цветового пространства (вероятно, между inftee и мостовым приемником).

Чтобы помочь вам отладить подобные проблемы, вы можете создать пустой файл c:\gmfbridge.txt, и код моста создаст журнал, включая настройки временных меток и задержку.

Образец GMFBridge демонстрирует, что вы можете разделить задачу на несколько отдельных графов с очень небольшими накладными расходами, и по этой причине он позволяет избежать копирования данных или добавления новых потоков в конвейер доставки. Однако для некоторых задач это слишком сложно, и более подходящим является более простое, более развязанное решение, например пул буферов с рабочим потоком ниже по течению.

С другой стороны: смарт-тройник удаляет временные метки из вывода предварительного просмотра, поэтому сэмплы, расположенные ниже тройника, визуализируются сразу после их поступления. В обычном графике захвата сэмплы имеют временную метку времени захвата — если вы передаете их непосредственно в средство визуализации, они всегда будут опаздывать для визуализации. Правильным решением является настройка временных меток для задержки от захвата до рендеринга, но грубое решение удаления временных меток работает в большинстве случаев. Smart Tee делает это, дублируя объект IMediaSample, но указывая на тот же буфер данных (таким образом, он копирует метаданные, но не данные). Обратите внимание, что смарт-тройник также отбрасывает сэмплы в выводе предварительного просмотра, если считает (согласно эвристике 1996 г.), что вывод захвата отстает.

G

person Geraint Davies    schedule 18.09.2009
comment
Спасибо, Герайнт. Я собирался опубликовать эту ссылку в своей ветке форума DirectShow, но я вижу, что вы тоже ее нашли. Я поместил его туда, так как, как новый пользователь StackOverflow, я не могу добавить некоторые теги, которые, по моему мнению, были более актуальными, и решил, что мой вопрос здесь просто затеряется среди всего остального. - person ; 18.09.2009