how to differentiate between valid and invalid NALU in AVCC?

Question

I have a mp4 file that has only video data without moov atom. I have parsed the SPS, PPS. I'm trying to decode the video frames and NALU in this data. When I process each byte of this data to find NALU, I'm getting a false NALU because in RBSP data there are some bytes which are similar as NALU header (0x65, 0x01, 0x21, 0x61). The video data is in AVCC format, not in Annex B so I cannot find the start code to know the starting of the NALU. Is there anything with i can compare the NALU size to find out that it is a valid NALU or not?

Answer 1

I guess you have MP4 'mdat' atoms with some h.264 payload data in each one. Or maybe you have RFC 6184 payload data. You didn't say.

You should look at the first 'mdat' atom to look for your SPS and PPS NALUs.

That 'mdat' atom probably looks something like this.

 ---length-- m  d  a  t
 00 00 07 a9 6d 64 61 74 

    ---length-- SPS atom......... NALU id 7 ................  
    00 00 00 0f 67 42 c0 14 8c 8d 41 42 2f 2c 03 c2 21 1a 80

    ---length-- PPS atom...  NALU id 8
    00 00 00 04 68 ce 3c 80 

    ---length-- pix ... 
    00 00 00 ed 65 b8 00 04 00 00 09 fd b9 48 88...

In other words, each NALU in the 'mdat' starts with a four-byte length, then the NALU. It can also be a three-byte or two-byte length (two-byte is pretty doggone useless). RFC 6184's definition of Single Time Aggregation Units calls for four-byte lengths.

If the stream is in annexB, each NALU starts with either 00 00 01 or 00 00 00 01 rather than a length.

SPS and PPS NALUs don't have a fixed size. And they're hard to parse because their contents are coded using a variable-length scheme called exponential Golomb coding. So your best bet, if you possibly can, is to find their boundaries and treat them as opaque, but variable-length, chunks of bytes.

I put together some Javascript to parse SPS and PPS NALUs because I had a similar problem to yours.