We have a hardware capture card creating a VC1/Wmv stream that we feed into a Media Foundation topology. The stream is rendered just fine, but when writing to disk, using an IMFSinkWriter, sometimes delta frames are dropped resulting in smearing until next key frame. The sink writer does not have any encoder associated, the input and target media types are equal.
We are quite certain that this is caused by the sink writer deliberately dropping frames in order to keep the average bit rate within limits. If we set the video stream (in hardware) to approx 3 MBit/s, the same bitrate value is used as target media type in a call to AddStream on the sink writer. If the input stream (again created in hardware) is overshooting the target, we see dropped frames down in the writer.
If we (using the same 3Mbit/s stream) tell the sink writer we have a 6Mbit/s target media type, no frame drops seems to occur.
The big question is then: How can we prohibit the sink writer from dropping frames. We have set MF_MT_ALL_SAMPLES_INDEPENDENT to FALSE and we have tried changing the MF_SINK_WRITER_DISABLE_THROTTLING but this doesn't seem to help.
The follow up is: How can we detect if frame drop occurs? We can of course see it in the resulting file where samples are missing, but we don't seem to get any information from the sink writer. Even the IMFSinkWriter GetStatistics method reports all samples being processed.
Could the frame drop be a buffer overflow issue? We have read about the leaky bucket buffering, but we havn't been able to configure these options on our sink writer (which is created using MFCreateSinkWriterFromURL).
As a workaround, could someone describe the consequences of having a wmv file with an erroneous (too large) average bit rate information in its header?
Regards Björn
Bjorn