locked
NullTransform imlementation of IMFTransforms deadlocks RRS feed

  • Question

  • Hi,

    I am working on a WinStore app and want to perform a video processing of a wmv file. Though I do not need a sound stream. To truncate it I created a NullTransform MFT which is plugged in a MF pipeline via the WinRT Windows.Media.Transcoding.MediaTranscoder's AddAudioEffect method.

    In the transform's GetOutputStreamInfo method I set the MFT_OUTPUT_STREAM_PROVIDES_SAMPLES flag so that the pipeline does not create output samples.

    In the transform's ProcessInput method I do not store IMFSample (do not touch it at all) and always return S_OK flag.

    In the transform's ProcessOutput method I always return MF_E_TRANSFORM_NEED_MORE_INPUT flag, hence pipeline have to supply new samples to ProcessInput method.

    All methods of my transform are guarded with the critical section.

    When I profile the execution of a program which completes successfully, all threads (a lot of them - 16 or so) contend for some lock(s) inside the pipeline's internal code.

    The solutions works well for small files, but for files >4Gb the pipeline at some moment (after minute or two) hangs, CPU utilization becomes 0% and all threads become blocked.

    What can cause such a behavior?

    Tags: WMF, IMFTransform, pipeline

    Monday, September 24, 2012 6:30 PM

All replies

  • This is caused by two seperate Media Foundation behaviors.  One is that file sinks try to group samples from around the same timestamp before packetizing them and writing them out to the file.  If one stream is not providing samples at around the desired timestamp, the sink will block requests on other streams until that stream catches up.  The other behavior is that the ASF source has a hard limit on how much data it will buffer in memory.  Once it reaches this limit, it will block indefinitely.

    Essentially what your MFT does is completely drain the audio stream on the ASF source, leaving a large amount of video data buffered in memory.  The sink wants audio samples at an early timestamp for packetization, so it stops requesting video data.  If the ASF source reaches the buffered data in memory limit before the audio stream reaches the end, the pipeline will hang.

    To get the same sort of sound stream 'removal' without hitting this issue, your MFT could generate samples filled with audio silence.  If the audio format is 8 bit PCM, overwrite all bytes with 0x80.  Otherwise, just zero out the buffer.  This results in a little bit of extra time spent encoding the audio stream and a slighly larger file, but it gets the job done.

    Thursday, October 25, 2012 10:56 PM