Showing results for 
Search instead for 
Did you mean: 

IPP5.3 H264 Decoding

Hello, I'm decoding a live H264 network stream and I'm feeding it to the H264 decoder. Here's what happens: when calling GetFrame() I receive UMC_ERR_NOT_ENOUGH_DATA for a constant number of frames, and after that I get UMC_OK and I can display the video stream. Why is that ? The first frame always has SPS, PPS and IDR_SLICE info, so it's a *keyframe* and therefore it should be perfectlly possible to display it without having to wait for the next frames in the stream ? The constant number of frames I have to wait before I get a proper image is dependant on the resolution: ie:

2560x1900 I get the image instantly without gettting the UMC_ERR_NOT_ENOUGH_DATA

1920x1200 wait 1 frame (first frame returns UMC_ERR_ NOT_ENOUGH_DATA, the next one is ok)

960x592 wait 8 frames (9th is displayable and all that follow)

340x244 wait 15 frames (16th is ok) and so on...

* the above resolution are approximations (I use resolutions in the proper "divisible" format)

It looks like IPP H264 decoder needs to fill up some kind of buffer before returning a valid frame. Still, why can't I get a proper frame right after passing a *COMPLETE* keyframe (SPS + PPS + IDR_SLICE) ?

ps. I'm using w_ipp_samples_p_5.3.095 and use static linking with dispatching
0 Kudos
2 Replies


There is a workaround for this problem. You can get the buffered frames by calling GetFrame with NULL in parameter. I understand that in H264 an inter frame can reference many other frames, so this is why it is required to buffer some frames, but it would be nice to know, why we can't get the decoded picture normally after feeding the IDR frame to the decoder. And of course, it would be nice to know if there's a plan to change this behaviour in the future?

Best Regards,

Thanks for the tip. Getting frames with GetFrame( NULL ) now works, but still I have to first call GetFrame with input data, receive the NOT_ENOUGH_DATA return value, and *then* call GetFrame again, this time with NULL value. This works ok, but it would be more efficient if it would be possible to *force* getting the buffered data with just one GetFrame call ;)