H.264 NALU vs AnnexB FOURCCs?

kcdixon · 10th July 2009, 17:34

When dealing with H.264 content, I've seen various FOURCCs associated with them, such as

avc1
AVC1
H264
h264

Which of these are standard? Also, is one used to refer to NALU streams vs AnnexB streams?

akupenguin · 10th July 2009, 18:16

4ccs simply aren't standard. Anyone writing an app that needs to match 4cc to format has to look at the de facto population of files in the wild, not at some central registry.
There is no "NALU vs AnnexB". All h264 streams contain NALUs, and AnnexB is one encoding thereof. The alternate encoding is sometimes called "avc1" since it is used in mp4 and mp4's 4cc for h264 is "avc1". It's also sometimes called just "avc", even though h264 as a whole is also called "avc".
However, the encoding is not determined by 4cc. If you found an avi file whose 4cc is "avc1" (perish the thought), chances are it's still AnnexB, because that's what people use in avi.

kcdixon · 10th July 2009, 18:26

Thanks akupenguin,

The reason I ask, is some file splitters/demuxers seem to give a stream of AnnexB, and some have already split up the stream into NALU.

I guess AVI is an exception, but generally I would expect that you would want to store NALU in a container format, since AnnexB is just an example of a way to separate the NALU, while container formats should supply their own method of delimiting. What's been everyone's experience on this matter?

akupenguin · 10th July 2009, 19:02

Container formats usually delimit frames. H264 streams can contain multiple NALUs per frame, and those need to be delimited too. You can either put that delimiting method in the h264 standard (AnnexB), implement it in the h264 codecs, and use that same code for all containers; or you can put it in the container standards, implement it in the muxers, and use the same code for all video formats.
If it were common for video formats to have NALUs, then either way would be a sensible division of labor. But most video formats have only one packet per frame, and h264 does have its own delimiter specification, so who wants to add a new feature to every container out there when you can just use AnnexB as an opaque blob per frame?

The only good exception I know is: rtp has container-level knowledge of NALUs so that you only lose one NALU instead of a whole frame in case of packet loss.
mp4 and mkv are also exceptions, but they don't have any such good reason.

kcdixon · 10th July 2009, 20:17

I've implemented RFC3984 before, so I'm familiar with that example. Thanks for the insight.

10th July 2009, 17:34	#1 \| Link
kcdixon Registered User Join Date: Jun 2009 Location: CA Posts: 8	H.264 NALU vs AnnexB FOURCCs? When dealing with H.264 content, I've seen various FOURCCs associated with them, such as avc1 AVC1 H264 h264 Which of these are standard? Also, is one used to refer to NALU streams vs AnnexB streams?

10th July 2009, 19:02	#4 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	Container formats usually delimit frames. H264 streams can contain multiple NALUs per frame, and those need to be delimited too. You can either put that delimiting method in the h264 standard (AnnexB), implement it in the h264 codecs, and use that same code for all containers; or you can put it in the container standards, implement it in the muxers, and use the same code for all video formats. If it were common for video formats to have NALUs, then either way would be a sensible division of labor. But most video formats have only one packet per frame, and h264 does have its own delimiter specification, so who wants to add a new feature to every container out there when you can just use AnnexB as an opaque blob per frame? The only good exception I know is: rtp has container-level knowledge of NALUs so that you only lose one NALU instead of a whole frame in case of packet loss. mp4 and mkv are also exceptions, but they don't have any such good reason. Last edited by akupenguin; 10th July 2009 at 19:09.

10th July 2009, 18:16	#2 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	4ccs simply aren't standard. Anyone writing an app that needs to match 4cc to format has to look at the de facto population of files in the wild, not at some central registry. There is no "NALU vs AnnexB". All h264 streams contain NALUs, and AnnexB is one encoding thereof. The alternate encoding is sometimes called "avc1" since it is used in mp4 and mp4's 4cc for h264 is "avc1". It's also sometimes called just "avc", even though h264 as a whole is also called "avc". However, the encoding is not determined by 4cc. If you found an avi file whose 4cc is "avc1" (perish the thought), chances are it's still AnnexB, because that's what people use in avi.

10th July 2009, 18:26	#3 \| Link
kcdixon Registered User Join Date: Jun 2009 Location: CA Posts: 8	Thanks akupenguin, The reason I ask, is some file splitters/demuxers seem to give a stream of AnnexB, and some have already split up the stream into NALU. I guess AVI is an exception, but generally I would expect that you would want to store NALU in a container format, since AnnexB is just an example of a way to separate the NALU, while container formats should supply their own method of delimiting. What's been everyone's experience on this matter?

10th July 2009, 20:17	#5 \| Link
kcdixon Registered User Join Date: Jun 2009 Location: CA Posts: 8	I've implemented RFC3984 before, so I'm familiar with that example. Thanks for the insight.