The problem occurs when the parser/demux/decoder filter detects the
EOS (on a worker thread) and calls DeliverEndOfStream on both the
audio and video output pins. Only one of the bridge sink's input pins
gets the EndOfStream method called. This results in the
BridgeSink::OnEOS method only getting called once where the first EOS
is discarded. OnEOS does not get called a second time to invoke the
BridgeController's OnEndOfSegment method.
The parser/demux/decoder filter uses the COutputQueue class on it's
output pins and each output queue does queue a EOS_PACKET. I'm not
sure why BridgeSinkInput::EndOfStream is called on only one of the
bridge sink filter's input pins. It appears that one of the output
queue instances on the upstream filter's pins is not processing an
EOS_PACKET.
Any help is greatly appreciated...
I guess that the EOS has not reached the sink pin because there is a
queue of buffers waiting. These buffers are being held up by the mux,
waiting for more data from the other stream, which is at EOS. In a
single graph, the first EOS would reach the mux and tell it to finish
off without waiting for more data to balance the streams.
Here, I think you need to increase the buffering at the bridge so that
you can get all your data into buffers downstream of the bridge, even
with a disparity between the streams.
G