display delay

Hi,

In H.264 standard, there is a mechanism though wich you can support display re-ordering and this is not only limited to B frames but to also P frame. If we go through exact standard methos, codec has to wait till the whole DPB becomes full before it can release buffers for display(worst case 16).

To enable application display buffers sooner than the prescribed limit, we have a parameter called display delay parameter. As as example - If you set it to a value 3, the codec will start giving out display buffer after 3 process calls. But in case the input streams contains display re-ordering more than 3, the output may be junbled.

In most practical scenario, application will know the kind of stream it has to play, so it can set it approproately.

regards

Yashwant 

Hi Yashwant,

I read the Annex explaining the display delay concept. It all explained very well now, except with MPEG-2 decoder in which the display delay supported value are only:
* IVIDDEC3_DECODE_ORDER
* IVIDDEC3_DISPLAY_DELAY_1
Adding to this is that in our case the application does not know the stream it has to play (unless maybe the required information will exist also in the transport stream).
I would like to ask how we should configure MPEG-2 display delay ? Does the supported value put any limit on stream GOP structure ?

Thank you very much!

Ran

Ran,

Mpeg2 GOP structure is simple, it does NOT allow heriarchal coding where B frames can be used for reference. hence display delay of 1 is enough to take care of all GOPs.

Generally, the container format/transport stream will have information about the codec type, so you can configure the value accordingly. You also need codec type information to create the codec, otherwise how will your application know which codec it has to create to decode the frames.

regards

Yashwant

Hi Yashwant,

Does it mean that when using MPEG-2 decoder the GOP structure >MUST NOT< be used with more than 1 reference frame?

Best Regards,

Ran

Ran,

Mpeg2 does not support more than 1 reference frame, except in case of B frames where there can be 2 ref frame. But display delay does not have anything to do with number of reference frame supported. It is about how much out of sync "decode" and "display" order can be. And hence how much buffering codec should do in order to gaurentee correct display order.

regards

Yashwant