This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

h264 decoder throwing away good data in the presence of packet loss?

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?

Many thanks,


Alex

  • Hi Alex,

    We will check it and get back to you.

    Thanks,

    Veeranna

  • Hi Alex,

    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? 

  • Hi Veeranna,

    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. 

    Best regards,

    Alex

  • Hi Alex,

    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).

    Thanks,

    Veeranna

  • Hi Veeranna,

    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.

    Thanks,


    Alex