-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
write_nal_unit() function prints spare null byte at buf[0] #5
Comments
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:
should be changed to instead modify the first byte of the NAL unit resulting from the (later) call to rbsp_to_nal(). |
@antoneliasson Thank you very much. I manually changed the code as you suggested and it fixed my problem. |
Good. Could you please submit a pull request for your change? |
@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. |
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. |
I wanted to push the changes originally but I deleted the code and forgot about it. Will do now... |
I stumbled on this too... I was expecting:
but kept getting:
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 |
The text was updated successfully, but these errors were encountered: