Media (Intel® oneAPI Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools from Intel. This includes Intel® oneAPI Video Processing Library and Intel® Media SDK.
2965 Discussions

NAL generated for IDR frames are not conform the h264 standard


When the h264 encoder generates a keyframe, it is observed that the "nal_ref_idc" field is 0 for all nal's of that frame. Also for the IDR NAL. Somehow this is not giving issues when streaming via rtsp, but when recording it as transport stream (.ts) files the video is unbearable to watch due to missing reference picture.

Now I have to manually set the "nal_ref_idc" field when the encoding is done. Please adjust the encoder to comply to the standard.

According to the standard:

nal_ref_idc not equal to 0 specifies that the content of the NAL unit contains a sequence parameter set or a picture parameter set or a slice of a reference picture or a slice data partition of a reference picture.
nal_ref_idc equal to 0 for a NAL unit containing a slice or slice data partition indicates that the slice or slice data partition is part of a non-reference picture.
nal_ref_idc shall not be equal to 0 for sequence parameter set or sequence parameter set extension or picture parameter set NAL units. When nal_ref_idc is equal to 0 for one slice or slice data partition NAL unit of a particular picture, it shall be equal to 0 for all slice and slice data partition NAL units of the picture.
nal_ref_idc shall not be equal to 0 for IDR NAL units, i.e., NAL units with nal_unit_type equal to 5.
nal_ref_idc shall be equal to 0 for all NAL units having nal_unit_type equal to 6, 9, 10, 11, or 12.

0 Kudos
2 Replies

It appears that I have been creating IDR frames which are not reference frames, therefore the NAL was also incorrect.

My mistake, when using IDR frames that are also reference frames there is no problem. This topic can be closed.


Hi Krist, 

MSDK H.264 implementation does comply with ISO*/IEC* 14496-10 and ITU-T* H.264 standard. Glad you were able to resolve this issue. Sure, will close this thread.