locked
Playback stops after stream change (Error: 0xC00D36B2) RRS feed

  • Question

  • Hi,

    I'm having problems during playback after making a stream change.  My topology is a MFSource-->MyDecoder-->EVR.  The source is the windows demuxer for MP4V video.  Because the input format is compressed, my decoder does not know the output format until after a some data has been processed.  Once it knows, it will return MF_E_TRANSFORM_STREAM_CHANGE in IMFTransform::ProcessOutput and also set the status flag to MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE.  Once this is done, I can see calls being made to re-negotiate the output type and everything seems to work properly and in proper order.  After IMFTransform::SetOutputType is called, IMFTransform::ProcessOutput is called like before but right after that completes, playback stops with an error code of (0xC00D36B2).  I made sure my transform does not specify MFT_OUTPUT_STREAM_PROVIDES_SAMPLES or MFT_OUTPUT_STREAM_CAN_PROVIDE_SAMPLES.

    I do notice the maximum length of the buffers I get from the output samples match the sizes from the old format however.  I'm not sure this is relevant.  I also tried setting the initial format to something different than the actual format but still using the same image size (ie. NV12 -> I420).  In this case, the buffer sizes after the stream format change matches the new format but still playback will fail with the same error code.

    For playback, I just create a Media Session, create a topology with the source, decoder, and EVR and set the topology with the

    MFSESSION_SETTOPOLOGY_IMMEDIATE flag and then call IMFMediaSession::Start.

    Thanks!


    • Edited by Stanley T Monday, August 22, 2011 9:35 PM Adding more details
    Monday, August 22, 2011 9:27 PM

Answers

  • I found if I changed my topology to as follows (MFSource --> MyDecoder --> Color Conversion DMO --> EVR), then dynamic streams work properly.  In case this is useful to anyone, the CLSID for this MFT is {98230571-0087-4204-B020-3282538E57D3}.

    Monday, August 29, 2011 6:04 PM

All replies

  • I found if I changed my topology to as follows (MFSource --> MyDecoder --> Color Conversion DMO --> EVR), then dynamic streams work properly.  In case this is useful to anyone, the CLSID for this MFT is {98230571-0087-4204-B020-3282538E57D3}.

    Monday, August 29, 2011 6:04 PM
  • I would expect the EVR to handle most color format changes without issue, but color format support is dependent upon the graphics card and it is possible that the new color space is not one supported by the graphics card.  The color conversion DMO would be able to convert the color space to one supported by the EVR.

    If the pipeline cannot negotiate a new media type after a format change, it tries to continue streaming using the old format.  This is known internally as the 'try our luck' code path, because the trace line this situation generates says something to the order of 'cannot negotiate new output type.  Set old format and try our luck.'  Our luck must be pretty terrible because I do not think this code path has ever worked after the format change.

    Wednesday, September 21, 2011 9:58 PM