GMFBridge
Fix for surface-loss problem
GMBridge build 1.0.0.18 is available, with a fix for surface loss issues that have been reported by a number of people.
What I believe happens is the following:
- Graph A is a capture and preview graph, containing a capture source feeding both the bridge sink and a preview renderer.
- Graph B is a file writer, with the bridge source feeding a mux and the file writer filter.
- During capture, when the graphs are bridged and running, a display change occurs. This can be ctrl-alt-del, or a screen resolution change, or moving the window to another monitor.
- In some cases, (VMR9 windowless mode, for example), the default handling for this event is to stop and restart the graph. This will stop and restart only graph A, the preview graph, leaving graph B (file writer) still running.
- When graph A starts delivering data again, the timestamps are reset to zero. However, there was no bridge disconnect or connect operation, so the bridge controller does not detect the time change.
- The mux receives data timestamped at zero, and rejects the sample as out-of-order, so writing is aborted.
The problem is that bridge controller does not handle the stop and restart correctly while still bridged. I've modified the sink filter to detect a stop and restart while still bridged, and on the next data delivery it will trigger the bridge source's reconnect logic, so the timestamps will be mapped correctly.
28 April 2009