I observed something peculiar when working with the VPU decoder. The imx-vpu API informs me about how many framebuffers I need to prepare and register. According to the VPU API manual PDF, the minFrameBufferCount value in the DecInitialInfo indicate the minimum number of framebuffers required for decoding. So, using this minimum number should in theory be enough. Except, it isn't.
With some h.264 streams that use the h.264 high profile, I observed that this minimum is not enough. When retrieving information about the output picture by calling vpu_DecGetOutputInfo(), sometimes the indexFrameDisplay value of the DecOutputInfo struct contains the value -3. The VPU docs say about value -3 : "There is temporarily no display output even without any action by the host application. Usually, this value occurs when an IDR picture is received for H.264 display-reordering mode." Until now, I was working around this by allocating 6 extra framebuffers in addition to the number specified by minFrameBufferCount. With this, I never get -3.
Now, my question is: when I receive the index -3 , should I consider the frame dropped? Or just delayed? The text I quoted above indicates the latter, but I'd like some confirmation for this.
The -3 should occur because there is no display output but should not drop the frame, only re-order it, if it makes sense.
Are you playing the video straight or skipping/rewinding? H.264 encoding configuration may change the ability to perform these actions with or without temporary distortion.
Just straight playback. I have observed that the -3 value in indexFrameDisplay occurs in groups, followed by equally large groups of negative values in indexFrameDecoded. I am investigating this. Perhaps I can introduce an internal queue to queue up encoded frames. My findings will go to the libimxvpuapi library.