Maximum lookahead value for dvsdk_3_10_00_16 codecs

Hi Aloke,

Are you saying that the 2 scenarios which you mentioned happens for normal streams also ? Its not possible for codec to just keep a displayed frame infinitely and not release it, similarly releasing a buffer without marking it for display is also not possible.

If you have a stream which can reproduce this problem, we can try to check that out.

regards

Yashwant

Hi Yashwant,

We find this behaviour of buffer loss (consumed by the decoder) when a stream is run repeatedly as described in:

http://e2e.ti.com/support/embedded/linux/f/354/t/153921.aspx

 The buffers are gradually lost and at some point the buffers are no more available for circulation between the decoder and display threads. Would you be able to run this test as described? If yes, we could give you the test stream.

Regards,

Alok

Basically we are interested in the maximum look ahead value for each of the codecs as described in the original question. Could you please provide us this information?

This looks more specific to DVSDK, will move to linux forum.

regards

Yashwant

This query was posted here in multimedia secton since we have seen buffers being held by the codec infinitely leading to a situation where there are no more buffers left for circulation between decoder and display threads.

Tracking the usage and status of buffers in the buffer table using BufTab_Print(), we see that the buffer mask for some buffers is marked DISPLAY_FREE mask since it was provided for display using Vdec2_getDisplayBuf() but not marked CODEC_FREE as it was not returned in Vdec2_getFreeBuf(). Similarly, there are cases where the buffers are marked CODEC_FREE but not DISPLAY_FREE.

Let us know where we can upload the stream that you can use for your testing. Please test using the setup described in http://e2e.ti.com/support/embedded/linux/f/354/t/153921.aspx

Hi,

Can you please provide the FTP details to upload the test data.

Hi Alok,

What is the resolution of the stream that you are decoding? Also, if I understand correctly, you are sharing buffers between the decoder and the display. How many buffers are you allocating in total?

Regards,

Kapil

Hi Kapil,

We have faced similar problem(as the one mentioned in opening post) while decoding streams with resolutions 720p as well as 1080i.

Yes, We are sharing buffers between the decoder & the display threads just as in dvsdk samples. At present We have 7 buffers allocated and registered with decoder.

Thanks,

Alok

Alok,

I think the problem might be that we are allocating too few buffers. For 1080 decode can you increase the number of buffers to 9 and check? I am assuming you are decoding Level 4.0 H264 streams.

If by allocating 9 buffers for 1080 decode, it does not hang, then we know that the number of buffers is the problem.

Regards,

Kapil

Hi Kapil,

We have already tested the output with increased number of buffers(up to 14) & the observed output is that the hang happens a little later, but the problem can still be seen.

Let me clarify the question & What we are looking for again:

It is clear that during the course of decoding decoders need to hold back certain buffers so as to decode some future video frames which need references from previous frames (b and p frames to be precise).  We had discussed this problem with Feroz and were told that indeed this is a problem encountered before in one of his projects. His workaround that time was to implement an ageing logic in the application where in the buffers held by decoder after a certain "age" can be considered for explicit freeing by the application. In order to implement this "age" logic, We want to know the look ahead value(no of buffers which video decoder can hold) during decoding. As We understand and was confirmed by Feroz, these values should be well defined for the said versions of the decoder and we need to know them.

Regards,

Alok

Alok,

I guess Feroz was talking about MPEG2 decoder. In H264 decoder, it is impossible to use this 'aging ' logic. There could be cases when a frame is always used as a reference for the entire sequence. The application can free up a buffer only if the decoder sends the BufferID in freeBufId array. Note that the freeBufID is an array and the decoder can free up more than 1 buffer at a time.

For H264, the number of reference buffers varies with resolution, level. For 1080 decode@Level4, we need to allocate 9 buffers. For 720p decode@Level4 we need to allocate 19 buffers (if we are sharing the buffers between decoder and display).

Have you already tried with allocating 9 buffers for 1080 decode and 19 buffers for 720p decode?

If yes, then we need to check if the streams are error streams. If it is error stream, then it is possible that the decode is not handling these error streams properly.

Regards

Kapil

Kapil,

For 1080i we have already tried with up to 14 buffers. Also, the decoder provides the facility where by you can query the buffers its going to require. So our code queries the decoder and provides the buffers it requires, that ensures we are providing the required number of buffers.

We have already put out an FTP which shares the said stream buffer and communicated the details before in a mail chain, You can pick up the same data dump for running your tests.In case you want me to share the credentials again please let me know the email id where I can send them.

Regards,

Alok