Weird last bit in Slice NAL Unit ...

[alex.buisson]

Hi,
i'm devolopping a transcoder using an encoder / decoder source code,
it's work fine on several stream,
but i found several .h264 file in which i found slices with a really strange bit.

At the end of each slice, the last bit of the last byte is always set to 1 and i don't see any reason for that!
It looks like this bit is never parsed and doesn't contribute in the decoding processing

i see the last MB cabac data, the slice terminating bit, and the end cabac, some stuffing bit (0) and always a 1.....

Have you an idea of what this 1 is ?

[Guest]

Can you post a link to a small sample please?

[Dust Signs]

If you have an Annex B stream, it is very likely that this is part of the trailing bits at the end of the NALU (so that it ends at a whole byte position). If present, it consists of a one bit, followed by as many zero bits as needed to reach a whole byte position. For further information, see 7.4.1, syntax element "rbsp_byte[ i ]", the paragraphs belonging to "rbsp_trailing_bits( )", especially:
ii) The next bit consists of a single rbsp_stop_one_bit equal to 1.
iii) When the rbsp_stop_one_bit is not the last bit of a byte-aligned byte, one or more
rbsp_alignment_zero_bit is present to result in byte alignment.


Best regards
Dust Signs

[alex.buisson]

Hi,
i put a sample in https://docs.google.com/open?id=0BxpKFXPCGGNNNWZWSkR2dlpyaDA

at 0x599 in that file you should see "34 21 00 00 00 01 01"
The end of a nalu/slice and the start code of the next nalu.
When i transcode this sample, the encoder rewrite everything bit-exact except the 0x21....
it look like the 0x20 (100000) is the correct value to finish the slice encoding .... the 1 is the end-of-cabac bit ! all others 0 are stuffing.

So why the original stream contain 100001 ?