locked
IMFSinkWriter quit working RRS feed

  • Question

  • My code used to output a large .mp4 file (e.g. 4MB) that I could successfully play in WMF12.  Since the last time I tested this feature, however, the file being produced is only 677 bytes and WMF12 complains "... might not support the file type ... or codec ...".

    I'm pasting a reduced collection of statements from my code that are being executed.  I've traced with breakpoints and every step is happening.  The return result is S_OK every time, including the WriteSample() call.  Yet it seems samples are NOT begin written to the file.

    I've included below the output from my own TraceAttributes() function as well.  I believe I was indeed using a combination of pType2 and pType, as the code shows.  I did try changing the AddStream to use pType rather than pType2, but doing so caused the SewtInputMediaType to return 0xC00D5212 (... no codec ...)

    This is at the limit of my understanding of Media Foundation.  What might be the reason it doesn't work?  And remember, it used to work, although I can't say for sure what code elements might have changed a little since then.

    IMFSinkWriter           *m_pWriterProcessedImage;
    			
    			........................................
    			
    			hr = MFCreateSinkWriterFromURL(
    				FILENAME,
    				NULL,
    				NULL,
    				&m_pWriterProcessedImage
    				);
    
    			.......................................
    
    			hr = m_pWriterProcessedImage->AddStream(pType2, psink_stream);
    			hr = m_pWriterProcessedImage->SetInputMediaType(*psink_stream, pType, NULL);
    			hr = m_pWriterProcessedImage->BeginWriting();
    			
    			TraceAttributes("for AddStream()", pType2);
    				**BEGIN OUTPUT FROM TraceAttributes**
    					STREAM ATTRIBUTES: for AddStream()
    						Type				= {73646976-0000-0010-8000-00AA00389B71}
    						Subtype				= {34363248-0000-0010-8000-00AA00389B71}
    						bitrate				= 2400000
    						size				= 640 x 480
    						frame rate			= 30.000000 (30000/1000)
    						pixel aspect		= (1/1)
    						interlace			= 2 (progressive)
    						{AD76A80B-2D5C-4E0B-B375-64E520137036}: <UNRECOGNIZED>
    						{3C036DE7-3AD0-4C9E-9216-EE6D6AC21CB3}: <UNRECOGNIZED>
    						{261E9D83-9529-4B8F-A111-8B9C950A81A9}: <UNRECOGNIZED>
    						{9AA7E155-B64A-4C1D-A500-455D600B6560}: <UNRECOGNIZED>
    				**END OUTPUT FROM TraceAttributes**
    			TraceAttributes("for SetInputMediaType()", pType);
    				**BEGIN OUTPUT FROM TraceAttributes**
    						STREAM ATTRIBUTES: for SetInputMediaType()
    							Type				= {73646976-0000-0010-8000-00AA00389B71}
    							Subtype				= {3231564E-0000-0010-8000-00AA00389B71}
    							bitrate				= 15373949
    							size				= 640 x 480
    							frame rate			= 30.000000 (30000/1000)
    							pixel aspect		= (1/1)
    							interlace			= 2 (progressive)
    							stride				= 640
    							independent samples	= 1
    							fixed size samples	= 1
    							sample size			= 460800
    							user data			= 460800
    				**END OUTPUT FROM TraceAttributes**
    			
    			......................................
    			
    			hr = m_pWriterProcessedImage->WriteSample(0, pSample); **THIS GETS CALLED MULTIPLE TIMES**
    
    			........................................
    			
    			hr = m_pWriterProcessedImage->Finalize();
    

    Tuesday, June 11, 2013 12:37 PM

Answers

  • FIXED.

    FYI, the original version that worked must have inherited the sample duration in the sample from the incoming stream.  But the current code wasn't explicitly setting it.  Adding a call to pSample->SetSampleDuration() fixed the problem.  So, the WriteSample() returned S_OK because it thought it did the correct thing, writing out nothing each time since each time the frame had zero duration.

    • Marked as answer by Dr..Lightning Tuesday, July 16, 2013 5:37 PM
    Tuesday, July 16, 2013 5:37 PM

All replies

  • CA 2 LA:

    Thanks sincerely for offering something at all.  However, simply a link to a tutorial isn't very useful.  

    I read through this tutorial, nevertheless.  I'm already doing all the germane things.  Remember, I have prior code that worked.

    I went back to an old version of the code and confirmed that it works.  However, my current code doesn't. The actions taken with respect to the sink writer are unchanged.  I confirmed this with a trace on both versions.  I also confirmed the stream attributes are identical between the two versions, so the problem shouldn't be a stream attributes snafu.

    I double checked the sample times, just in case that was messed up, and they look OK.  Nevertheless, I cloned the old code, that was SetSampleTime'ing them to 33000, 66000, 100000, 133000, etc.  That didn't help.  I had thought that perhaps the reason WriteSample did nothing is because it thought the current sample was always in the future or too far in the past.  But my cloning test just now suggests that this is not the case.

    The real timing of when WriteSample gets called has changed somewhat, due to complicated changes in my front end.  Is it still somehow possible that this timing is the cause?  Also, the content and origin of the samples has changed.  But I would think that as long as the stream attributes are identical, sample content changes should make no difference, even if the content is actually wrong or inconsistent with the stream attributes (a situation I believe not to be the case, anyway).  

    Nevertheless, out of all of this, shouldn't WriteSample return something other than S_OK if it's not going to write anything, whatever the reason?  That's not happening.  WriteSample is returning S_OK yet not writing anything.

    Tuesday, June 11, 2013 6:33 PM
  • FIXED.

    FYI, the original version that worked must have inherited the sample duration in the sample from the incoming stream.  But the current code wasn't explicitly setting it.  Adding a call to pSample->SetSampleDuration() fixed the problem.  So, the WriteSample() returned S_OK because it thought it did the correct thing, writing out nothing each time since each time the frame had zero duration.

    • Marked as answer by Dr..Lightning Tuesday, July 16, 2013 5:37 PM
    Tuesday, July 16, 2013 5:37 PM