Я использую превосходное 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.Я не заметил, что этот параметр десинхронизировал мои уже работающие графики, и я обвинял фильтр моста.
В итоге я облажался:
Запуск графа муксера из потока, отличного от приложенияthread (поток, обрабатывающий цикл событий графа).
Переключатель задержки в восходящем фильтре, который, вероятно, слишком сильно задерживает работу мультиплексора, чтобы поддерживать работу.