GMF Bridge and EC_VMR_RENDERDEVICE_SET problem
-
2012年3月8日 21:27
I am using the GMF bridge with a single source graph and 2 sink graphs as such:
The goal is to be able to independently start and stop the streaming sink graph and the playback graph. For simplicity, audio streaming and playback is not performed here but is included in the final design.
The custom Bridge Transform Filter performs a copy of the media samples from the infinite pin tee filter and provides an interface for optionally stripping the timestamps.
The source graph has the sink streams running in discard mode so both sink graphs could run without a bridged sink graph.
The bridge transform filter before the playback bridge sink is stripping timestamps and the playback sink graph is running with a NULL reference clock since the source is live. The bridge transform filter before the streaming sink bridge is not stripping the timestamps and the streaming sink graph is using a default reference clock.
This design is working well except in situations where the render device gets reset, EC_VMR_RENDERDEVICE_SET event, as a result of the screensaver kicking in or the video display window being dragged to a different monitor. When this happens, the playback sink graph ceases to play video. The streaming sink graph also stops sometimes, based on different testing configurations. Windows 7 reports that The color scheme has changed to Windows 7 Basic from the Aero theme when attempting to restart the video playback.
The screensaver session change events, WTS_SESSION_LOCK and WTS_SESSION_UNLOCK are monitored. The different testing configurations mentioned include the various ways the playback graph is stopped, started, disconnected and reconnected in response to these session change events and the EC_VMR_RENDERDEVICE_SET event. The goal is to have the streaming sink graph continue to stream the live data and also have the video continue to play or recover to a playing state.
I have tried unbridging and re-bridging the source and playback sink graphs, stopping and starting the playback sink graph, and even destroying and rebuilding the playback sink graph in various combinations without success.
In some cases the streaming continues, but the video playback never recovers. This occurs with and without the streaming sink graph bridged to the source graph. The suggested work around is to stop and restart both source and sink graphs, but this would stop the streaming graph and disconnect any streaming clients.
