We are using the very latest h264 decoder on a dm368 based board. We are running in low latency mode and we have observed that as soon as the decoder sees a missed packet for a frame, it gives up on decoding that frame even if later packets for the frame are available. Is this correct?
For example: consider a frame divided into 4 slices, with 1 slice per packet. Packet 1 arrives and is decoded by the decoder which then calls our callback function. Packet 2 is lost, but Packets 3 and 4 are available. If we return Packet 3 to the decoder it comes out of the process function with an error without calling our callback again to get Packet 4.
The result of this is that at least two (probably three) slices were not decoded, because one slice was missing. This is not very good for error resilience. Are we doing something wrong? What should the callback function return to the decoder in the case where the decoder is expecting packet 2, but it has been lost and only packets 3 and 4 are available?
We will check it and get back to you.
In reply to Veeranna Hanchinal:
We need more inputs;
In your case frame has 4 slices and 2nd slice packet is missed. And what application is passing to second callback? is it packet 3 or null?
What error code decoder is returning?
Thanks for picking this up.
>In your case frame has 4 slices and 2nd slice packet is missed. And what application is passing to second callback? is it packet 3 or null?
It would be really helpful if you could tell me what I should be returning here. I can't find anything in the documentation to say. What I observe is that if I return zero data in the call back then the decode process early-terminates (which makes sense to me). If I return packet 3 then the decoder also early-terminates, outputs a decoded frame along with non-fatal errors about missing MBs/corrupted data. What I want it to do is to carry on asking for packet 4 through the callback, and then return with the non-fatal error.
The odd thing is we're now finding that sometimes it does accept packet 3 and goes on to ask for packet 4, so this may well be something we're doing wrong. However what would really help us debug this is to establish what the decoder is supposed to do, and the correct way to use the callback function in the case of lost packets.
In reply to Alex Nancekievill:
For 2nd callback application should provide 3rd packet. Normally Decode process call will not come out till it reaches End of Picture, it will also come out when callback function returns error(zero blocks or zero base ptr).
Thank you for that. I have marked this answer as verified so we can close this thread. I will debug our application against this expected behaviour and let you know if I hit any problems with it.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.