It returned you a frame but didn't use input data, so you should use this frame until next call, I don't see contradiction here. And this document statement is true only if you don't use your own frame buffer.That should be a safe assumption, but this does go against what the documentation says about GetFrame: "An obtained decoded frame is supposed to be used only until the next GetFrame is called."
This it is not suppose to do. Can you provide stream with such problem?The other funky thing is that sometimes calling GetFrame with a NULL input will still return UMC_ERR_NOT_ENOUGH_DATA. If you call it a second time in a row with a NULL input then it will return UMC_OK and give you the decoded frame.
h264 decoder in umc 6.x and umc 7.x have different threading pipelines. The reason of this behaviour may be is that decoder doesn't have enough buffer to store new frame but between calls secondary thread has finished decoding of a buffered frame and it is ready for output.This behavior is also slightly confusing to me as well since if the frame could be returned without reading any data then why was it not returned with the previous GetFrame call.