write_nal_unit() function prints spare null byte at buf[0] about h264bitstream HOT 8 OPEN

This is probably a side effect of rbsp_to_nal() starting the NAL buffer with a zero byte. I am interpreting the reason for this behaviour to be that the first byte in the resulting NAL is reserved for the NAL header. But write_nal_unit() puts the NAL header first in the RBSP stream before passing it to rbsp_to_nal(), causing the extra zero byte.

If this is the intended behaviour of rbsp_to_nal(), lines 1059-1062 in h264_stream.c which currently do the following:

    bs_t* b = bs_new(rbsp_buf, rbsp_size);
    /* forbidden_zero_bit */ bs_write_u(b, 1, 0);
    bs_write_u(b, 2, nal->nal_ref_idc);
    bs_write_u(b, 5, nal->nal_unit_type);

should be changed to instead modify the first byte of the NAL unit resulting from the (later) call to rbsp_to_nal().

from h264bitstream.

@antoneliasson Thank you very much. I manually changed the code as you suggested and it fixed my problem.

from h264bitstream.

Good. Could you please submit a pull request for your change?

from h264bitstream.

@antoneliasson @skirsten This sounds like a serious bug, but I'm not sure I completely understand what the bug is supposed to be.

Per the standard, nals may start with either 0x00 00 00 01 or 0x00 00 01. When writing, h264bitstream always uses the longer form (regardless of what it was when that nal was read in - if it was read in). This is consistent with eg x264 which always writes the longer form.

from h264bitstream.

You are talking about the start code prefix, which can be either 0x00 00 01 or 0x00 00 00 01 (for 16-bit alignment purposes if I remember correctly). The start code prefix must be immediately followed by the NAL Unit header. The bug is that your application inserts a zero byte between the start code prefix and the NAL Unit header.

from h264bitstream.

I wanted to push the changes originally but I deleted the code and forgot about it. Will do now...
Edit: Nevermind I have no clue what I changed...

from h264bitstream.

I stumbled on this too...

I was expecting:

SPS: 00 00 00 01 67 42 00 0a f8 41 a2 
PPS: 00 00 00 01 68 ce 38 80 

but kept getting:

SPS: 00 67 42 00 0a f8 41 a2 
PPS: 00 68 ce 38 80 

Anyway, I worked around it by just writing 3 bytes ahead in the buffer then overwriting the first four bytes with the start code. I.e. replace write_nal_unit(stream, buffer, size) with (write_nal_unit(stream, buffer + 3, size - 3) + 3).

from h264bitstream.

I guess there was a confusion between "NAL unit syntax" (7.3.1) and "byte stream NAL unit syntax" (B.1.1). The latter begins with "leading_zero_8bits":

from h264bitstream.