- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am working on a directshow filter (a simple transform filter) in order to encode MPEG-4.
I seem to run into a problem with the output. The output (once decoded) show the image with black and magenta vertical stripes on the entire image.
I have tried specifying various colorspaces with little change.
The following is a snippet of the code I have tested from the Transform() fn:
if (!m_bEncoderInitialized)
{
OutputDebugString(_T("Initializing Encoder\r\n"));
if (!m_pEncoder)
m_pEncoder = new(std::nothrow) UMC::MPEG4VideoEncoder();
if (m_pEncoder)
{
m_EncoderParams.info.clip_info.width = inWidth;
m_EncoderParams.info.clip_info.height = inHeight;
m_EncoderParams.info.color_format = m_colorspace;//UMC::YUY2;
if ((status = m_pEncoder->Init(&m_EncoderParams)) != UMC::UMC_OK)
{
sprintf(out_msg,"Error %i in init\r\nw:%i h:%i format:%i",status,inWidth,inHeight,m_EncoderParams.info.color_format);
OutputDebugString(out_msg);
return S_FALSE;
}
if ((status = m_pEncoder->GetInfo(&m_EncoderParams)) != UMC::UMC_OK)
{
sprintf(oot,"Error %i in m_pEncoder->getInfo\r\n",status);
OutputDebugString(oot);
return S_FALSE;
}
status = m_DataIn.Init(inWidth,inHeight,m_colorspace,8);
m_bEncoderInitialized = TRUE;
}
else
{
OutputDebugString(_T("Error allocating memory for encoder instance"));
return S_FALSE;
}
}
m_DataIn.SetBufferPointer(pSrc, lInBuffSize);
m_DataIn.SetDataSize(lInBuffSize);
PBYTE pTempBuffer = new(std::nothrow) BYTE[pOut->GetSize()];
m_DataOut.SetBufferPointer(pTempBuffer,pOut->GetSize());
// Encode!!!
if ((status = m_pEncoder->GetFrame(&m_DataIn,&m_DataOut)) != UMC::UMC_OK)
{
sprintf(out_msg,"Error %i in m_pEncoder->GetFrame <>\r\n",status);
OutputDebugString(out_msg);
return S_FALSE;
}
The encoder initialization only occurs one the first call into Transform().
Any thoughts as to what I could be doing wrong?
Thanks for any info.
Dave
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dave,
What is the real format in yourinput data?
In general, the encoder ask UMC::YV12 format as default input, that means, your data is stored as Y first, follow U, follow V. The total size for one frame is imgWidth*imgHeight*3/2. If your input are other format, may you try to contert it into YV12, then feed it into the encoder and see if it can work normally?
You may have know, there is a simple encoder sample at
http://software.intel.com/en-us/articles/getting-started-with-intel-ipp-unified-media-classes-sample/
for your reference.
Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Ying H (Intel)
Hi Dave,
What is the real format in yourinput data?
In general, the encoder ask UMC::YV12 format as default input, that means, your data is stored as Y first, follow U, follow V. The total size for one frame is imgWidth*imgHeight*3/2. If your input are other format, may you try to contert it into YV12, then feed it into the encoder and see if it can work normally?
You may have know, there is a simple encoder sample at
http://software.intel.com/en-us/articles/getting-started-with-intel-ipp-unified-media-classes-sample/
for your reference.
Regards,
Ying
Hi Ying,
Dave's buffer seems to be YUY2 (YUYV "422" packed), the simple encoder sample requiers YV12(YVU) or iYUV(YUV) "420"planar format (UMC converts YV12 to iYUV and vise versa, automatically.. I wonder why? its just the UV order reversing!) .
Then Dave must convert from YUY2 (packed 422) to iYUV/YV12 (planar 420).
ipp format convertion function: ippiYCbCr422ToYCbCr420_8u_C2P3R
regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Tamer Assad
Hi Ying,
Dave's buffer seems to be YUY2 (YUYV "422" packed), the simple encoder sample requiers YV12(YVU) or iYUV(YUV) "420"planar format (UMC converts YV12 to iYUV and vise versa, automatically.. I wonder why? its just the UV order reversing!) .
Then Dave must convert from YUY2 (packed 422) to iYUV/YV12 (planar 420).
ipp format convertion function: ippiYCbCr422ToYCbCr420_8u_C2P3R
regards,
Hi Tamer,
Thanks foryour correct. Yes, strictly speakingtheIPP sample require YUV4:2:0 (planar) format as input, not YV12(YVU).
if dave have YVY2(packed) format, then he must do color conversion first.
case YUY2->YUV420
status = ippiYCbCr422ToYCrCb420_8u_C2P3R(pSrc[0], pSrcStep[0], pDst, pDstStep, srcSize);
I thinkthere is not special reason to select YUV4:2:0 as input, may be justbecauseYUV4:2:0 is widely and easily to used.
Best Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ying,
Thank you for your confirmation.
The function:
ippiYCbCr422ToYCrCb420_8u_C2P3R(pSrc[0], pSrcStep[0], pDst, pDstStep, srcSize);
will result in placing:
1) the Y component (plan) in the pDst[0]
2) the Cr component (plan) in the pDst[1]
3) the Cb component (plan) in the pDst[2]
this is more like a YV12.
Function:
ippiYCbCr422ToYCbCr420_8u_C2P3R(pSrc, srcStep, pDst, dstStep, roiSize);
will result in placing:
1) the Y component (plan) in the pDst[0]
2) the Cb component (plan) in the pDst[1]
3) the Cr component (plan) in the pDst[2]
this is more like an iYUV sequence.
infact they are pretty much the same, its just the sequence of the chroma components sequence differs, and must be considered when passing the plans pointer.
iYUV 420 is commonly used for video coding (ex.MPEG-2 and 4) and it provides a more compact (less size) in image (frame) color sampling as each pixel is presented by 1.5 byte.
Also, you are right Ying, iYUV is the prefered format by UMC. Thanks again for the confirmation.
Best regards,
Tamer
Thank you for your confirmation.
The function:
ippiYCbCr422ToYCrCb420_8u_C2P3R(pSrc[0], pSrcStep[0], pDst, pDstStep, srcSize);
will result in placing:
1) the Y component (plan) in the pDst[0]
2) the Cr component (plan) in the pDst[1]
3) the Cb component (plan) in the pDst[2]
this is more like a YV12.
Function:
ippiYCbCr422ToYCbCr420_8u_C2P3R(pSrc, srcStep, pDst, dstStep, roiSize);
will result in placing:
1) the Y component (plan) in the pDst[0]
2) the Cb component (plan) in the pDst[1]
3) the Cr component (plan) in the pDst[2]
this is more like an iYUV sequence.
infact they are pretty much the same, its just the sequence of the chroma components sequence differs, and must be considered when passing the plans pointer.
iYUV 420 is commonly used for video coding (ex.MPEG-2 and 4) and it provides a more compact (less size) in image (frame) color sampling as each pixel is presented by 1.5 byte.
Also, you are right Ying, iYUV is the prefered format by UMC. Thanks again for the confirmation.
Best regards,
Tamer
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page