I am trying to creata an ASF file holding a VC-1 compressed video stream,
using a sequence of uncompressed video as the samples.  The samples are 8 bit
SD video captured with an AJA frame grabber card, or UYVY in the vernacular
of the Windows Media Format.  The issue I am having is that every other call
to IWMWriter::WriteSample() fails with a return code of NS_E_INVALID_DATA.

One area I suspect is a problem is the so-called "bit fields" that are said
to be required for 16bpp uncompressed samples ( 2nd paragraph in the remards 
seciton on the topic of "WMVIDEOINFOHEADER" in the Windows Media Format 11 
SDK ).  In the description below, as part of step 10 I could allocate this 
bit field and fill it with something - but I am not sure what to do here?

  I am using the Windows Media Format 11 SDK for the first time and suspect I
am making an obvious blunder some where but have not been able to uncover it.

  What I am doing (with error checking eliminated):
       1) I used the applicaton GenProfile.exe to create a profile (and also 
the 
          Windows Media Profile Editor to review and modify).
		Video Size is 720x508
		CBR 770 Kbps
		I have tried with and without interlace processing with no effect
                (The actual video is interlaced)

       2) Create the Writer Object and get an interface
		hr = WMCreateWriter( NULL, &m_pWriter );
		hr = m_pWriter->QueryInterface( IID_IWMWriterAdvanced, ( void** ) 
&m_pWriterAdvanced );

	3) Open the profile, read it in, set it equal to a WCHAR string
		char * prof_768  = "VS_CBR768-100-kf8.prx";
		char * prof_file = prof_768_prog;
		FILE* pfid = fopen( prof_file, "r" );

		fseek(pfid, 0, SEEK_END);
		long nbytes = ftell(pfid);
		rewind( pfid );

		char * pProfileString = (char*)malloc( sizeof(char) * nbytes );
		size_t nread = fread( pProfileString, sizeof(char), nbytes, pfid );

		WCHAR* pwProfString = (WCHAR*) pProfileString;


	4) Create the profile Manager
		IWMProfileManager* pProfMgr = NULL;
		hr = WMCreateProfileManager( &pProfMgr );

	5) Load profile into the profile Manager
		IWMProfile *pProfile = NULL;
		hr = pProfMgr->LoadProfileByData( pwProfString, &pProfile );


	6) Get a StreamConfig interface
		IWMStreamConfig *pStreamConfig = 0;		
		hr = pProfile->GetStreamByNumber( 1, &pStreamConfig ); // assuming we only 
have one stream in the profile

	7) Associate this profile with the Writer
		hr = m_pWriter->SetProfile( pProfile );

	8) Get the Stream Connection by Name and get the input to the writer that 
has the same name
           ( this uses the function FindInputByConnection() which is a
             slight modification of the function GetNamesForInputs() listed
             in Step 2: of WMF 11 SDK topic:  "To Enumerate Input Formats" )
		hr = pStreamConfig->GetConnectionName( pwcStreamConnName, &numChar );
		hr = FindInputByConnection( m_pWriter, pwcStreamConnName, 
&dwWriterInputForStream );


	9) Find the desired format from all supported formats on this input
               -> I want packed YUV data in the UYVY byte order --> UYVY
		Use the function FindInputFormat() which is part of help topic "To 
Enumerate Input Formats"
		IWMInputMediaProps *piwmInputMediaProps = NULL;
		hr = FindInputFormat( m_pWriter, dwWriterInputForStream, 
WMMEDIASUBTYPE_UYVY, &piwmInputMediaProps);

	10) Assign the format to the input
		hr = piwmInputMediaProps->GetMediaType( NULL, &cbSize );
		int bitfieldsize = 2; // ??? how big and what to do??
		WM_MEDIA_TYPE* pType = (WM_MEDIA_TYPE*) new BYTE[cbSize + bitFieldSize];
		hr = piwmInputMediaProps->GetMediaType( pType, &cbSize );

		pType->cbFormat = cbSize + bitFieldSize;
		WMVIDEOINFOHEADER* pVidHdr = (WMVIDEOINFOHEADER*) pType->pbFormat;
		BITMAPINFOHEADER*   pBMHdr = &(pVidHdr->bmiHeader);
		char* pBitField = ((char*)pType->pbFormat) + sizeof(WMVIDEOINFOHEADER) ;
		FillMemory( pBitField, bitFieldSize, 0xff );

		hr = piwmInputMediaProps->SetMediaType( pType );
		hr = m_pWriter->SetInputProps( dwWriterInputForStream, piwmInputMediaProps);


	11) Add a file sink for the Writer object
		hr = m_pWriter->SetOutputFilename( pwcFN ); 

	12) start adding samples...
		hr = m_pWriter->BeginWriting();
		INSSBuffer* pSampBuf = NULL;
		INSSBuffer3 *pSampBuf3 = NULL;
		BYTE* pSampBufData = NULL;

		for( )
		{
			// allocate a INSSBuffer
			hr = m_pWriter->AllocateSample(  FrameSize, &pSampBuf );

			// get a pointer to the data
			hr = pSampBuf->GetBufferAndLength( &pSampBufData, &buflen );

			// copy uncompressed video data into the buffer
			m_VideoEngineFile.ReadFrame(0, &fr_time, pSampBufData );

			// set buffer length
			pSampBuf->SetLength( buflen );

			// Set sample time
			QWORD sampTime = (QWORD) (1e7 * (iSample * 1.0/29.97) + .5);

			// Set up the sample flags
			if( iSample == 0 )
			{
				sample_flags = WM_SF_CLEANPOINT | WM_SF_DISCONTINUITY | WM_SF_DATALOSS;
			}
			else
			{
				sample_flags = NULL;
			}

			// Finally - write the sample
			hr = m_pWriter->WriteSample( dwWriterInputForStream, sampTime, 
sample_flags ,pSampBuf ); // fails on about every other sample with a Sample 
Is Not Valid

			// release buffer
			SAFE_RELEASE( pSampBuf );
			SAFE_RELEASE( pSampBuf3 );

		}


	13) End writing and close file
		m_pWriter->EndWriting();

From: "RandPendleton"

> One area I suspect is a problem is the so-called "bit
> fields" that are said to be required for 16bpp
> uncompressed samples ( 2nd paragraph in the remards
> seciton on the topic of "WMVIDEOINFOHEADER" in the
> Windows Media Format 11 SDK ).  In the description below,
> as part of step 10 I could allocate this bit field and
> fill it with something - but I am not sure what to do
> here?

That applies to biCompression == BI_BITFIELDS, which is RGB, 
not to YUV formats.

http://msdn2.microsoft.com/en-us/library/ms532290(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/ms779712(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/ms787838(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/ms788178(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/ms788140(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/ms787796(VS.85).aspx

Read all of them, even if they seem to repeat themselves.

>  I am using the Windows Media Format 11 SDK for the first
> time and suspect I am making an obvious blunder some
> where but have not been able to uncover it.

I don't think the profile or the input format is your 
problem, since you should otherwise be getting a failure 
when you set those.

> // get a pointer to the data
> hr = pSampBuf->GetBufferAndLength( &pSampBufData, &buflen
> );
>
> // copy uncompressed video data into the buffer
> m_VideoEngineFile.ReadFrame(0, &fr_time, pSampBufData );
>
> // set buffer length
> pSampBuf->SetLength( buflen );

buflen is either 0 or MaxLength, which >= FrameSize. You 
should set it to the actual used frame buffer size 
(FrameSize?) otherwise, with fixed-size frames like YUV, the 
write will fail.


-- 
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

"Alessandro Angeli" wrote:

> That applies to biCompression == BI_BITFIELDS, which is RGB, 
> not to YUV formats.
> 
> http://msdn2.microsoft.com/en-us/library/ms532290(VS.85).aspx
> http://msdn2.microsoft.com/en-us/library/ms779712(VS.85).aspx
> http://msdn2.microsoft.com/en-us/library/ms787838(VS.85).aspx
> http://msdn2.microsoft.com/en-us/library/ms788178(VS.85).aspx
> http://msdn2.microsoft.com/en-us/library/ms788140(VS.85).aspx
> http://msdn2.microsoft.com/en-us/library/ms787796(VS.85).aspx
> 

Very informative - thank you!


> 
> I don't think the profile or the input format is your 
> problem, since you should otherwise be getting a failure 
> when you set those.
> 

  I don't think so either as I did a test where I changed from YUV input 
data, to RGB 24 bpp, making the appropriate changes.  This I was able to 
successfully write to an asf file.



> buflen is either 0 or MaxLength, which >= FrameSize. You 
> should set it to the actual used frame buffer size 
> (FrameSize?) otherwise, with fixed-size frames like YUV, the 
> write will fail.

I do set it to the actual used frame buffer size: 1097280 for RGB 24bpp and 
731520 for YUYV.   These are also the numbers returned from the call to 
GetBufferAndLength().

It seems I have either not set a parameter correclty for YUYV or need to set 
a parameter that I have not.   Ideas?

Thank you .

From: "RandPendleton"

> It seems I have either not set a parameter correclty for
> YUYV or need to set a parameter that I have not.   Ideas?

What are the full contents of the 
WM_MEDIA_TYPE+WMVIDEOINFOHEADER of your input format?


-- 
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

"Alessandro Angeli" wrote:

> What are the full contents of the 
> WM_MEDIA_TYPE+WMVIDEOINFOHEADER of your input format?
> 

On the IWMWriter interface I search and find an input format of
 type: WMMEDIASUBTYPE_UYVY

WM_MEDIA_TYPE  contents are:
	majortype = {73646976-0000-0010-8000-00AA00389B71}
	subtype = {59565955-0000-0010-8000-00AA00389B71}
	bFixedSizeSamples = 1
	bTemporalCompression = 0
	lSampleSize = 731520
	formattype = {CLSID_WDM Streaming Capture VideoInfoHeader Data Type Handler}
	pUnk = 0x00000000
	cbFormat = 160
	pbFormat = 0x003588d0 ""

casting pbFormat to a (WMVIDEOINFOHEADER*) yields:

WMVIDEOINFOHEADER contents are:
        rcSource  = {top=0 bottom=508 left=0 right=720}
        rcTarget = {top=0 bottom=508 left=0 right=720}
	dwBitRate = 0
	dwBitErrorRate = 0
	AvgTimePerFrame = 333667
	bmiHeader = {biSize=40 biWidth=720 biHeight=508 ...}

  the data fields of the bmiHeader are:
	biSize = 40
	biWidth = 720
	biHeight = 508
	biPlanes = 1
	biBitCount = 16
	biCompression = 1498831189  [ biCompression = 0x59565955  ]
	biSizeImage = 731520
	biXPelsPerMeter = 0
	biyPelsPerMeter = 0
	biClrUsed = 0
	biClrImportant = 0




> -- 
> // Alessandro Angeli
> // MVP :: DirectShow / MediaFoundation
> // mvpnews at riseoftheants dot com
> // http://www.riseoftheants.com/mmx/faq.htm 
> 
> 
>

I'm not sure this is your issue, but:

                       // Set sample time
                        QWORD sampTime = (QWORD) (1e7 * (iSample *
1.0/29.97) + .5);

                        // Set up the sample flags
                        if( iSample == 0 )
                        {
                                sample_flags = WM_SF_CLEANPOINT |
WM_SF_DISCONTINUITY | WM_SF_DATALOSS;
                        }
                        else
                        {
                                sample_flags = NULL;
                        }

...I don't think you'd ever need to set the sample flags for
uncompressed samples, nor would you want to.  Discontinuity is largely
used for audio, IIRC, and cleanpoint is to force the writer to set a
sample as a keyframe.  Dataloss isn't used, from what I can see.

What is dwWriterInputForStream end up being when you call WriteSample?


Lastly, a totally unrelated suggestion: use smart pointers.  Writing
WMFSDK or DShow code without doing so is begging for reference
counting issues.

From: "RandPendleton"

> On the IWMWriter interface I search and find an input
> format of type: WMMEDIASUBTYPE_UYVY

The format structure looks correct so the problem should be 
elsewhere.

-- 
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

"Jeremy Noring" wrote:

> ....I don't think you'd ever need to set the sample flags for
> uncompressed samples, nor would you want to.  Discontinuity is largely
> used for audio, IIRC, and cleanpoint is to force the writer to set a
> sample as a keyframe.  Dataloss isn't used, from what I can see.
> 

  That makes sense to me - when it the WriteSample was failing I started 
taking stabs at what could be the issue and adding the sample flags was one 
of those attempts.

> What is dwWriterInputForStream end up being when you call WriteSample?
> 

dwWriterInputForStream  =  0;

I think this is okay, as when I change my input samples from 720x508 YUYV to 
720x508 RGB samples (and changing the input properties I set on the writer 
input ) then I am able to write an ASF file.


> 
> Lastly, a totally unrelated suggestion: use smart pointers.  Writing
> WMFSDK or DShow code without doing so is begging for reference
> counting issues.
> 

Thank you for the advice!  This is my first time playing down in the WMFSDK 
so any advice is welcome.

"Alessandro Angeli" wrote:

> The format structure looks correct so the problem should be 
> elsewhere.
> 

I wanted to investigate the stream properties for signs of errors.  I 
downloaded the Wiindows Media ASF Viewer to help me compare two ASF files - 
one of which appears to have the correct encoding (but was created with a 
standalone demo app) and the other which is the result of my program.  It 
appears there are extra bits in the Bitmap info for both.  Do these results 
help point out any problems?


ClipB_out2.asf was created by transcoding an avi file consisting of motion 
jpeg compressed YUYV data 720x508, using the MainConcept encoder to a VC-1 
video stream in an asf file.  It's Stream properties object is listed here:

Stream Properties Object / Bitmap Info Header: 
biSize 64   
Width 720   
Height 508   
Planes 1   
Bits 16   
Compression TEXT: WVC1
0000: 57 56 43 31                                       WVC1   
Image Size 0   
X Pels / Meter 0   
Y Pels / Meter 0   
Colors Used 0   
Colors Important 0   
Extra Data Size 24   
Extra Data 0000: 01 00 00 01 0F DA 00 16-70 FD 0A 16 78 3F 68 0C  
                0010: 88 00 00 01 0E 4C 10 80 


Temp.asf is the result of my app (which fails on every other WriteSample() 
call, but results in an asf file with 0 packets in the Data Object).

Stream Properties Object / Bitmap Info Header: 
biSize 62   
Width 720   
Height 508   
Planes 1   
Bits 16   
Compression TEXT: WVC1
0000: 57 56 43 31                                       WVC1   
Image Size 0   
X Pels / Meter 0   
Y Pels / Meter 0   
Colors Used 0   
Colors Important 0   
Extra Data Size 22   
Extra Data 0000: 27 00 00 01 0F CB D8 16 70 FD 88 80 00 00 01 0E
                0010: 10 44 59 C3 F4 80

From: "RandPendleton"

> I wanted to investigate the stream properties for signs
> of errors.  I downloaded the Wiindows Media ASF Viewer to
> help me compare two ASF files - one of which appears to
> have the correct encoding (but was created with a
> standalone demo app) and the other which is the result of
> my program.  It appears there are extra bits in the
> Bitmap info for both.  Do these results help point out
> any problems?

Since you are encoding, the input and output media types are 
not related. WMV adds some extra bytes to the format block, 
but that's the output media type, filled in by the writer.

Have you tried to modify the UncompAVIToWMV sample to source 
blank UYVY frames and see whether that one works?

-- 
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm