Фильтр GMFBridge DirectShow SetLiveTiming эффект - PullRequest
0 голосов
/ 14 сентября 2018

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

Мой исходный график источника захватывал видео в реальном времени со стандартных видео и аудио входов.

В фильтре GMFBridgeController есть недокументированный метод с именем SetLiveTiming().Исходя из названия, я решил, что это должно быть установлено на true, если мы собираем данные из графика Live (не из файла), как в моем случае.Я установил это значение на true, и все заработало как положено

Такое же оборудование захвата позволяет мне захватывать телевизионные сигналы в реальном времени (ATSC в моем случае), поэтому я создал новую версию графика, используя архитектуру BDAфильтры, для тюнинга.Когда данные вытекают из демультиплексора MPEG, остальная часть графика практически совпадает с моим исходным графиком.

Однако в этот раз мой график мультиплексирования (на другой стороне моста) не работал.Данные поступали из фильтра BridgeSource (видео и аудио) и поступали на фильтр муксера MP4, однако не поступало никаких данных с выхода муксера, питающего фильтр FileWriter .

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

Может кто-нибудь просветитьЯ имею в виду реальную цель настройки SetLiveTiming() и, возможно, почему один график работает с включенным параметром, а другой не работает?

ОБНОВЛЕНИЕ

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

ОБНОВЛЕНИЕ 2: Пропущенные образцы были введены тем, как я запустил вторичное устройство (мультиплексор)граф.Я проверил образец, используя SampleGrabber (таким образом, внутри потокового потока) в качестве точки триггера, и использовал вызов Task.Run() .NET для создания экземпляра графа мультиплексора.Это каким-то образом испортило часы, и у меня закончилось создание «контрольной начальной точки» в будущем - когда мост попытался исправить временную метку путем вычитания контрольной начальной точки, он произвел отрицательную временную метку - как только я исправил это и породил график изВ потоке приложения (после публикации события графика) проблема была исправлена.

К сожалению, мое мультиплексированное видео (независимо от настройки SetLiveTiming()) все еще не синхронизировано .

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

Вот мой текущий исходный график:

                                                                   -->[TIF]
                                                                  |
 [NetworkProvider]-->[DigitalTuner]-->[DigitalCapture]-->[demux]--|-->[Mpeg Tables]
                                                                  |
                                                                  |-->[lavAudioDec]-->[tee]-->[audioConvert]-->[sampleGrabber]-->[NULL]
                                                                  |                        |
                                                                  |                        |
                                                                  |                         ->[aacEncoder]----------------
                                                                  |                                                       |--->[*Bridge Sink*]
                                                                   -->[VideoDecoder]-->[sampleGrabber]-->[x264Enc]--------

Вот мой график мультиплексора:

                      video  
 ...  |bridge source|-------->[MP4 muxer]--->[fileWriter]
             |                     ^
             |        audio        |
              ---------------------

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

ОБНОВЛЕНИЕ 3:

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

В итоге я облажался:

  1. Запуск графа муксера из потока, отличного от приложенияthread (поток, обрабатывающий цикл событий графа).

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

1 Ответ

0 голосов
/ 14 сентября 2018

Комментарий автора:

// using this option, you can share a common clock 
// and avoid any time mapping (essential if audio is in mux graph)
[id(13), helpstring("Live Timing option")]
HRESULT SetLiveTiming([in] BOOL bIsLiveTiming);

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

...