Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Superfluous bytes at the end of NAL units #1952
I just found out that one can use the Intel Quick Sync hardware decoder with ffmpeg and wanted to test/benchmark it, but on some files I got (not critical) errors like "missing picture in access unit with size 1" or size 2, but never more. I investigated the issue and found out that mkvmerge's output module for unframed H.264 is suboptimal: Sometimes one or two bytes after the end of a NAL unit are not stripped away. It is easy to produce example files exhibiting the issue: If one adds zeros to the startcode of a nal unit, one can see that 0x00 00 00 00 01 will result in an unnecessary 0x00 added to the preceding NALU (and the 0x00 00 00 01 will be treated as start code); if one adds another 0x00, two 00 are added; and if one adds even more 0x00, there are no trailing 0x00 at all.
In unframed h.264 streams such as the ones in MPEG TS files (or raw elementary streams) you cannot just add 0x00 bytes anywhere you want. In such streams the length of each stream is determined by looking for the next start code. 0x00 00 00 00 01 is not a valid start code, but 0x00 00 00 01 is. Therefore the newly added 0x00 (the first one) will be considered to be part of the preceding NALU.
I'm not saying mkvmerge doesn't have a bug, but I am saying that your testing method is wrong.
I'll look into the transport stream.
I know that one can't add 0x00 anywhere, but one can add it between two NAL units. If a parser finds a start code in a stream/file, it is the beginning of a new NAL unit and the last nonzero byte before this is by definition the end of the last