Интересна такая ситуация: Предположим, у нас есть источник видео с камеры с частотой 25 Гц и десяток трансформ-фильтров, присоединенных последовательно. Пусть каждый фильтр обрабатывает кадр за 20 мс, итого у нас будет задежка в 200 мс. Насколько я понимаю, в DS рендерер дропает кадры, если они придут слишком поздно. Вопрос: нелзя ли сделать так, чтобы эта цепочка работала как конвейер, т.е. чтобы видео показывалось с задержкой?
Моя идея: менять timestamp на каждом сэмпле с помощью IMediaSample::SetTime, чтобы продлить жизнь сэмплу. Я правильно мыслю?
Здравствуйте, Edge, Вы писали:
E>Интересна такая ситуация: Предположим, у нас есть источник видео с камеры с частотой 25 Гц и десяток трансформ-фильтров, присоединенных последовательно. Пусть каждый фильтр обрабатывает кадр за 20 мс, итого у нас будет задежка в 200 мс. Насколько я понимаю, в DS рендерер дропает кадры, если они придут слишком поздно. Вопрос: нелзя ли сделать так, чтобы эта цепочка работала как конвейер, т.е. чтобы видео показывалось с задержкой? E>Моя идея: менять timestamp на каждом сэмпле с помощью IMediaSample::SetTime, чтобы продлить жизнь сэмплу. Я правильно мыслю?
Не поможет. Тебе ж буферизовать надо, а для этого медиатаймы менять маловато будет Задержка то будет постоянно расти, при задержке в 10 секунд тебе уже надо будет 250 самплов хранить где то, да еще не дай бог то чтоб распакованные были. Ты лучше уж про SBE читай. Или не грузи capture graph тем чего он сделать не сможет.
Здравствуйте, Edge, Вы писали:
E>Интересна такая ситуация: Предположим, у нас есть источник видео с камеры с частотой 25 Гц и десяток трансформ-фильтров, присоединенных последовательно. Пусть каждый фильтр обрабатывает кадр за 20 мс, итого у нас будет задежка в 200 мс. Насколько я понимаю, в DS рендерер дропает кадры, если они придут слишком поздно. Вопрос: нелзя ли сделать так, чтобы эта цепочка работала как конвейер, т.е. чтобы видео показывалось с задержкой? E>Моя идея: менять timestamp на каждом сэмпле с помощью IMediaSample::SetTime, чтобы продлить жизнь сэмплу. Я правильно мыслю?
Цитата из MSDN:
"You can also set the filter graph to run with no clock, by calling SetSyncSource with the value NULL. If there is no clock, the graph runs as quickly as possible. With no clock, renderer filters do not wait for a sample's presentation time. Instead, they render each sample as soon as it arrives. Setting the graph to run without a clock is useful if you want to process data quickly, rather than previewing it in real time."
Смотри раздел про IFilterGraph::SetDefaultSyncSource
Здравствуйте, MAKCblM, Вы писали:
MAK>Цитата из MSDN: MAK>"You can also set the filter graph to run with no clock, by calling SetSyncSource with the value NULL. If there is no clock, the graph runs as quickly as possible. With no clock, renderer filters do not wait for a sample's presentation time. Instead, they render each sample as soon as it arrives. Setting the graph to run without a clock is useful if you want to process data quickly, rather than previewing it in real time."
Здравствуйте, aik, Вы писали:
aik>Не поможет. Тебе ж буферизовать надо, а для этого медиатаймы менять маловато будет
А на зачем мне буферизовать? Сэмпл проехал через фильтр до прихода следующего сэмпла и поехал дальше (с поправленым временем)...
aik>Задержка то будет постоянно расти, при задержке в 10 секунд тебе уже надо будет 250 самплов хранить где то, да еще не дай бог то чтоб распакованные были.
Ну и пусть общая задержка растет, меня волнует только то, чтоб на каждом фильтре она не превышала определенного времени. А насчет хранения сэмплов — это уже проблема фирмы Майкрософт
aik>Ты лучше уж про SBE читай. Или не грузи capture graph тем чего он сделать не сможет.
Ну, насколько я понял, SBE — это time-shifting от MS, тогда мне это не нужно. И, вообще, откуда ты знаешь, что capture graph этого не может?????
Здравствуйте, Edge, Вы писали:
E>Здравствуйте, MAKCblM, Вы писали:
MAK>>Цитата из MSDN: MAK>>"You can also set the filter graph to run with no clock, by calling SetSyncSource with the value NULL. If there is no clock, the graph runs as quickly as possible. With no clock, renderer filters do not wait for a sample's presentation time. Instead, they render each sample as soon as it arrives. Setting the graph to run without a clock is useful if you want to process data quickly, rather than previewing it in real time."
E>Нет, это не то.
Чем это не устраивает? Ты сам сказал, что надо чтоб граф работал не в реал-тайме, а если отключить синхронизирующие часы — то граф как-раз и будет работать так, как успеет. Поэтому это именно то. Или ты чего-то не так объяснил? Или я чего-то не так понял?
Здравствуйте, MAKCblM, Вы писали:
MAK>Здравствуйте, Edge, Вы писали:
E>>Здравствуйте, MAKCblM, Вы писали:
MAK>>>Цитата из MSDN: MAK>>>"You can also set the filter graph to run with no clock, by calling SetSyncSource with the value NULL. If there is no clock, the graph runs as quickly as possible. With no clock, renderer filters do not wait for a sample's presentation time. Instead, they render each sample as soon as it arrives. Setting the graph to run without a clock is useful if you want to process data quickly, rather than previewing it in real time."
E>>Нет, это не то.
MAK>Чем это не устраивает? Ты сам сказал, что надо чтоб граф работал не в реал-тайме, а если отключить синхронизирующие часы — то граф как-раз и будет работать так, как успеет. Поэтому это именно то. Или ты чего-то не так объяснил? Или я чего-то не так понял?
Однакось капчурка дропать начнет... есть такое предположение...
Здравствуйте, Sergey A. Sablin, Вы писали:
SAS>Здравствуйте, MAKCblM, Вы писали:
MAK>>Здравствуйте, Edge, Вы писали:
E>>>Здравствуйте, MAKCblM, Вы писали:
MAK>>>>Цитата из MSDN: MAK>>>>"You can also set the filter graph to run with no clock, by calling SetSyncSource with the value NULL. If there is no clock, the graph runs as quickly as possible. With no clock, renderer filters do not wait for a sample's presentation time. Instead, they render each sample as soon as it arrives. Setting the graph to run without a clock is useful if you want to process data quickly, rather than previewing it in real time."
E>>>Нет, это не то.
MAK>>Чем это не устраивает? Ты сам сказал, что надо чтоб граф работал не в реал-тайме, а если отключить синхронизирующие часы — то граф как-раз и будет работать так, как успеет. Поэтому это именно то. Или ты чего-то не так объяснил? Или я чего-то не так понял?
SAS>Однакось капчурка дропать начнет... есть такое предположение...
Здравствуйте, Sergey A. Sablin, Вы писали:
MAK>>Чем это не устраивает? Ты сам сказал, что надо чтоб граф работал не в реал-тайме, а если отключить синхронизирующие часы — то граф как-раз и будет работать так, как успеет. Поэтому это именно то. Или ты чего-то не так объяснил? Или я чего-то не так понял?
SAS>Однакось капчурка дропать начнет... есть такое предположение...
Виноват Я не понял что источник — capture filter
Но тогда хочешь-не хочешь, если в реал тайме не успеваешь обрабатывать, то либо весь ролик в буфера загонять, а если очень большой — то облом.
Здравствуйте, xp_alp, Вы писали:
_>Тут два варианта: либо ты отключаешь часики, и кадры начинают дропаться, _>либо создаешь буфер, который постоянно расти будет
Здравствуйте, Edge, Вы писали:
aik>>Не поможет. Тебе ж буферизовать надо, а для этого медиатаймы менять маловато будет E>А на зачем мне буферизовать? Сэмпл проехал через фильтр до прихода следующего сэмпла и поехал дальше (с поправленым временем)... aik>>Задержка то будет постоянно расти, при задержке в 10 секунд тебе уже надо будет 250 самплов хранить где то, да еще не дай бог то чтоб распакованные были. E>Ну и пусть общая задержка растет, меня волнует только то, чтоб на каждом фильтре она не превышала определенного времени. А насчет хранения сэмплов — это уже проблема фирмы Майкрософт aik>>Ты лучше уж про SBE читай. Или не грузи capture graph тем чего он сделать не сможет. E>Ну, насколько я понял, SBE — это time-shifting от MS, тогда мне это не нужно. И, вообще, откуда ты знаешь, что capture graph этого не может?????
может, но тебе надо решить проблему буферизации. как ты собираешься показывать кадры, который capture устройство уже отдало, а рендер еще не показал? передача сампла по фильтрам то традиционно синхронная. как вариант — вставляй чужой фильтр-буферизатор самплов. или пиши свой.
Здравствуйте, aik, Вы писали:
aik>может, но тебе надо решить проблему буферизации. как ты собираешься показывать кадры, который capture устройство уже отдало, а рендер еще не показал?
передача сампла по фильтрам то традиционно синхронная. как вариант — вставляй чужой фильтр-буферизатор самплов. или пиши свой.
Бррр. Так можно долго общаться . Короче, я поставлю эксперимент и расскажу, что получилось (Сделаю трансформ-фильтр с задержкой и буду химичить)...
Здравствуйте, Edge, Вы писали:
aik>>может, но тебе надо решить проблему буферизации. как ты собираешься показывать кадры, который capture устройство уже отдало, а рендер еще не показал? E>передача сампла по фильтрам то традиционно синхронная. как вариант — вставляй чужой фильтр-буферизатор самплов. или пиши свой.
E>Бррр. Так можно долго общаться . Короче, я поставлю эксперимент и расскажу, что получилось (Сделаю трансформ-фильтр с задержкой и буду химичить)...
химичить — эт завсегда пожалуйста, особенно если не горит и никто тебя за это не прибьет
просто я понимаю почему твоя фишка не пройдет, но объяснить русскими словами
Задержка то будет постоянно расти, при задержке в 10 секунд тебе уже надо будет 250 самплов хранить где то, да еще не дай бог то чтоб распакованные были. Ты лучше уж про SBE читай. Или не грузи capture graph тем чего он сделать не сможет.
Ты сам сказал, что надо чтоб граф работал не в реал-тайме, а если отключить синхронизирующие часы — то граф как-раз и будет работать так, как успеет. Поэтому это именно то. Или ты чего-то не так объяснил? 
Или я чего-то не так понял? 
Я не понял что источник — capture filter
