[Mp4-tech] Video bitstream parsing

[Max Griessl]

Hi Biswajit,
this do loop has been changed within the corrigenda
ISO/IEC 14496-2:2001/DCOR1 of the Fairfax meeting:
do{ macroblock() }
while ((nextbits_bytealigned() != resync_marker && 
nextbits_bytealigned() !=  000 0000 0000 0000 0000 0000 ) || 
valid_stuffing_bits() == 0)
5.2.9 Definition of valid_stuffing_bits() function
If the current position in not on a byte boundary, the function 
valid_stuffing_bits() returns 1 if the remaining bits in the current 
byte are valid stuffing bits. If the current position is on a byte 
boundary, valid_stuffing_bits() returns 1 if the remaining bits in the 
next byte are valid stuffing bits. Otherwise, valid_stuffing_bits() 
returns 0.
Hope this helps,
Max Griessl
Biswajit Acharya wrote:
> Hi,
> 
> I have the following doubt related to MPEG4 video stream parsing.
> 
> Problem statement :
>         According to the mpeg4 specs (14496-2), for decoding a VOP the
> do loop for the macroblocks is as given below
> 
>         do{
>                 macroblock()
>         } while (nextbits_bytealigned() != resync_marker &&
> nextbits_bytealigned()
>                 != ‘000 0000 0000 0000 0000 0000’)
> 
> 
> At the end of processing every macroblock, a check is done for the
> resync marker, or next start code from the next byte alinged position.
> 
> However, the problem may arise as shown in the following sequence :
> 
> Assume that there are M number of macroblocks in a VOP/video packet.
> Now, see the 1- byte data shown below.
> 
>                      byte boundary
>                         |
>                         |   
> 0  1  0  0  1  0  0  0  0 ……1
>             |           |
>             |           |
>     end of (M-3)rd MB   |
>                         |
>                 start of the resync marker/start code
> 
> 
> When the end of the (M-3)rd MB is reached, a check is made for the
> resync marker/start code from
> the next byte aligned portion. A start code/resync marker is found and
> the control exits the loop.
> 
> Now the problem is about these 3 bits ( 0 0 0) , that are in between the
> end of the macroblock and the next resync marker/start code. They may
> represent 3 not coded macroblocks or even some coded macroblocks, if its
> not all 0. 
> 
> If the bits after the end of MB and the next resync marker is 0 followed
> by 1, it is assumed to be stuffing bits and ignored. But what if the
> pattern is diffrent and actually represent some macroblocks.
> 
> 
> So the question is "How to handle such a situation?"
> 
> The Microsoft reference code does not implement the Do-While loop and
> instead decode VOP based on the total number of macroblocks. And this is
> not in line with the specs. Moreover, in case of any error in data
> stream it may gobble up the next start code/resync marker.
> 
> Kindly suggest a solution.
> 
> Regards,
> 
> B. Acharya
> 
> _______________________________________________
> Mp4-tech mailing list
> Mp4-tech lists.mpegif.org
> http://lists.mpegif.org/mailman/listinfo/mp4-tech