[Mp4-tech] Video bitstream parsing

[Chandra Sekhar Reddy]

Hi Biswajit Acharya,
Let me try to answer to some-extent.
Between the *last-bit of a packet* and the *first-bit of
next-packet-resync-marker (byte-aligned)", there shall exist *atleast-one*
and *atmost-eight* stuffing-bits.
If a packet *ends at a byte-boundary*, the next byte shall be "stuff-bits",
and then follows the next packet-resync-marker.
If a packet *ends in the middle of a byte*, the remaining bits in that byte
shall be filled with "stuff-bits", and then follows the next
packet-resync-marker.
The example-stream (seen in fixed-size font) given in your mail is *not
correct*.
Regards,
Chandra
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