This repository has been archived by the owner. It is now read-only.

Superfluous bytes at the end of NAL units #1952

Closed
mkver opened this Issue Apr 22, 2017 · 3 comments

Comments

2 participants
@mkver

mkver commented Apr 22, 2017

Hello,

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.
I have uploaded a transport stream (#1952.ts) which exhibits this behaviour (the block which gets timestamp 4826ms and has size 5491 is an example).

Greetings
Andi

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 22, 2017

Owner

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.

Owner

mbunkus commented Apr 22, 2017

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.

@mkver

This comment has been minimized.

Show comment
Hide comment
@mkver

mkver Apr 22, 2017

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 NAL RBSP (the thing that really matters). Section B.1.1 of the H.264 standard contains "trailing_zero_8bits /* equal to 0x00 */ " for this. And it seems that some transport streams contain more zero bytes than necessary.
I'm by the way not saying that mkvmerge has a bug. I'm just saying that this behaviour is suboptimal.

mkver commented Apr 22, 2017

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 NAL RBSP (the thing that really matters). Section B.1.1 of the H.264 standard contains "trailing_zero_8bits /* equal to 0x00 */ " for this. And it seems that some transport streams contain more zero bytes than necessary.
I'm by the way not saying that mkvmerge has a bug. I'm just saying that this behaviour is suboptimal.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 22, 2017

Owner

Ah, I see. Thanks for the pointer to the standard. I'll have to fix that, obviously. The h.265 parser most likely contains the same problem. I'll look into it, too.

Owner

mbunkus commented Apr 22, 2017

Ah, I see. Thanks for the pointer to the standard. I'll have to fix that, obviously. The h.265 parser most likely contains the same problem. I'll look into it, too.

mbunkus added a commit that referenced this issue Apr 22, 2017

mbunkus added a commit that referenced this issue Apr 22, 2017

mbunkus added a commit that referenced this issue Apr 22, 2017

@mbunkus mbunkus closed this Apr 22, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.