I would say this is probably a bug, but at the very least its a change from the old way it worked so it should be better documented.
Basically lets assume the decoder is only going to buffer one frame. What happens is you pass in the first frame to GetFrame and it returns UMC_ERR_NOT_ENOUGH_DATA as expected. The second time you pass in a frame it will return UMC_OK and your output buffer will be filled with the decompressed frame, however the input data will not have been read in. This is in contrast to how it worked in previous IPP sample code versions. To get around this you have to check the GetDataSize() of the input parameter and if it is non-zero then GetFrame didn't read it in and you'll have to call GetFrame again and assume its going to buffer the frame and not give you back another decoded frame. 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."
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.
I can work around these, but I would think this should be handled internally in the decoder rather than the consumer having to worry about it.