- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Selea,
Glad to know you make progress. and thank you very much to share your experience here.
You are exact right, the GetFrame() is not always produce a frame. There is some data remain in buffer.I guessthismay be the most importantpointwhendevelop H.264 decoderwith stream data.We may need take care of the loop and condition in the loop very carefully.
See the explanation in the UMC docu
Syntax virtual UMC::Status GetFrame(UMC::MediaData* pSrc, UMC::MediaData* pDst)
Description
The method processes data.
Ifthe user allocates input and output buffers. If GetFrame does
not use all data from the input buffer, the method updates data pointer, value of the actual
data in the buffer and start time.
If the codec uses internal frame buffering it can return UMC::UMC_ERR_NOT_ENOUGH_DATA
at the beginning of the processing. This error code means that the input data is buffered
but the output data is not ready to be delivered. The application has to continue to call
GetFrame with the next input data.
To retrieve buffered data at the end of the processing, the application should call GetFrame
with NULL input pointer while output is not empty.
(and ifwe did search, there aremany discussion about the h.264 decoder's delay or get UMC_ERR_NOT _ENOUGH_DATA in the forum.Unfortunately whentheapplication become large and complex, the basic problem weresubmerged)
With comment if (/*(3 > in->GetDataSize()) &&*/ andif (UMC_ERR_NOT_ENOUGH_DATA == ret)
{
if (bEndOfStream)
break;
// else
// continue;
}
//if (UMC_OK != ret)
// continue;
numDecodedFrames++;
printf("Frame decoder %d\n", numDecodedFrames);
I can't reproduce the crash, butI believedyou will getwrong result if discard someremain data by some condition clause.
For example, with above comment,iwill get 27 frame and thereal frame with thestream is 24 frame. some frame is actually black.
Best Regards,
Ying
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
if with
DataIn.SetBufferPointer(cVideoData,VideoDataSize);
DataIn.SetDataSize(VideoDataSize);
Params.m_pData = &DataIn; Params.lFlags=0; Params.numThreads=4;
if(status = H264Decoder.Init(&Params)!=UMC::UMC_OK)
return;
H264Decoder.GetInfo(&Params);
imgWidth=Params.info.clip_info.width; imgHeight=Params.info.clip_info.height;
it works fine.
how you to decode in 2 separeted thread? any detials?
Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I have tried static IPP library (both sequential(ipp*_l.lib) or parallel (ipp*_t.lib)).They can decompressyour stream fine.
So the problemlooks bemultiple threading. How do you create 2 threads by Win32 Windows API?Could you provide methe simple test code?
(if it is confidential, you may use private post).
Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Usually when I have to create 2 thread I use the function _beginthreadex.So you can create a function to decode the stream, create 2 thread with _beginthreadex that execute this function and run it at the same time. Try and let me know. Anyway I can reproduce the problem decoding even in 1 thread. Have you tried with the latest lib and sample?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After some days of try with the umc_h264_dec_con sample and my application I found the problem.
Was in my application, so I apologize with youYing to waste your time.
Anyway, I explain what was the problem.
Usually we read the H264 stream from the network or from an mkv video file: instead the samples works on a h264 bitstream. I make a H264->GetFrame on every frame I got, but I always consider that the decoder consume all the video data of the frame (usually it's so). Anyway in this particular case I got some frame that are not totally consumed but got me a complete image. For example I have a frame read from a the stream of 35kb and after GetFrame I have consumed only 15kb. I did not check the reamain bytes that now I put in the decoder again.
So probably after I wrong and discard the remain data without fill it in the GetFrame, next frame cause me a crash of the decoder.
Was my error, but I think you can check why the decoder crash.
To simulate the decoder crash change the sample code like this:
from
if ((3 > in->GetDataSize()) &&
to
if (/*(3 > in->GetDataSize()) &&*/
and comment out the continue; after initialization
try that with the 1280x720.h264 I attached and you can get the exception
let me know
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Selea,
Glad to know you make progress. and thank you very much to share your experience here.
You are exact right, the GetFrame() is not always produce a frame. There is some data remain in buffer.I guessthismay be the most importantpointwhendevelop H.264 decoderwith stream data.We may need take care of the loop and condition in the loop very carefully.
See the explanation in the UMC docu
Syntax virtual UMC::Status GetFrame(UMC::MediaData* pSrc, UMC::MediaData* pDst)
Description
The method processes data.
Ifthe user allocates input and output buffers. If GetFrame does
not use all data from the input buffer, the method updates data pointer, value of the actual
data in the buffer and start time.
If the codec uses internal frame buffering it can return UMC::UMC_ERR_NOT_ENOUGH_DATA
at the beginning of the processing. This error code means that the input data is buffered
but the output data is not ready to be delivered. The application has to continue to call
GetFrame with the next input data.
To retrieve buffered data at the end of the processing, the application should call GetFrame
with NULL input pointer while output is not empty.
(and ifwe did search, there aremany discussion about the h.264 decoder's delay or get UMC_ERR_NOT _ENOUGH_DATA in the forum.Unfortunately whentheapplication become large and complex, the basic problem weresubmerged)
With comment if (/*(3 > in->GetDataSize()) &&*/ andif (UMC_ERR_NOT_ENOUGH_DATA == ret)
{
if (bEndOfStream)
break;
// else
// continue;
}
//if (UMC_OK != ret)
// continue;
numDecodedFrames++;
printf("Frame decoder %d\n", numDecodedFrames);
I can't reproduce the crash, butI believedyou will getwrong result if discard someremain data by some condition clause.
For example, with above comment,iwill get 27 frame and thereal frame with thestream is 24 frame. some frame is actually black.
Best Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Jay
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just for your information,
Some H.264 decode issues are fixed in latest IPP sample version, includingthetwo
http://software.intel.com/en-us/forums/showthread.php?t=85271
and http://software.intel.com/en-us/forums/showthread.php?t=84628
Please try new version if possible,
Code Samples for the Intel Integrated Performance Primitives (Intel IPP) Library 7.0*
Regards,
Ying
http://software.intel.com/en-us/articles/intel-ipp-70-library-bug-fixes/
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »