[Mp4-tech] [H.264] Types of Picture order count and some questions

[WJ_Liu mtk.com.tw]

Hi guys,
I have some questions about POC as follows. 
For 8.2.1.1 picture order count type 0, PicOrderCntMsb is very important 
because it indicates four purposes in JVT-F044
(1) Records how many times pic_order_cnt_lsb has reached 
MaxPicOrderCntLsb,
(2) Two "wrapping over" situations: For example, if MaxPicOrderCntLsb=16, 
and in decoding order, <a> POC of current P frame is 14 and that of next 
one is 0; <b> POC of current P-frame is 0 and that of next B-frame is 14,
(3) For error resilience, POC is recoverable if the difference between 
pic_order_cnt_lsb of the picture before loss and pic_order_cnt_lsb of the 
picture after loss is less than MaxPicOrderCntLsb/2.
(4) Save some bits because only least significant bits of POC, stored in 
pic_order_cnt_lsb, are delivered. Most significant bits (PicOrderCntMsb) 
are estimated at decoder side.
Some questions are listed in the following, assuming that we only consider 
frame mode:
(1) A pattern with display order "IBPBP..." may be encoded as "IPBPB...", 
and its actual POC and pic_order_cnt_lsb of which may be "0, 4, 2, 8, 
6,...", such as the case used in JM. How can the decoder know if there are 
frames with POC 1 or 3 existed in the bitstream?
(2) A pattern with display order "IBBBBBP" may be encoded as "IPBBBBB", 
and the actual POC and pic_order_cnt_lsb of which may be "0, 12, 2, 4, 6, 
8, 10". However, according to (8-3), PicOrderCntMsb of P will be 
mis-calculated as -16 and its POC is -4, and POCs of the following Bs are 
also wrong.
(3) A pattern with display order "IBP1BP2BP3BP4BP5..." may be encoded as 
"IP1BP2BP3BP4BP5B...", and the actual POC of which may be "0, 4, 2, 8, 6, 
12, 10, 16, 14, 22, 20,..." and the sequence of pic_order_cnt_lsb is "0, 
4, 2, 8, 6, 12, 10, 0, 14, 4, 2, ...". If frames after P2 and before P5 
are lost, i.e., the sequece becomes "IP1BP2 (loss) P5B" and the actual POC 
is "0, 4, 2, 8, (loss) 4, 2, ...". The POC difference between the frame 
before loss and the one after loss is abs(4-8)=4, which is within the 
constraint 16/2=8. However, the POC estimated of P5 is 4, which is wrong. 
So, what is the robustness of error resilience ability? Can anyone suggest 
some literature about error resilience used in H.264?
(4) When POC estimated goes wrong, is there any other mechanism that can 
be used to recover that?
Thanks in advance.
Jerry
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s).  Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person.   Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20051215/1b9a59b3/attachment.html