MMcodecsH264C64XPLUSFAQ

H.264 Baseline decoder related queries

Does H.264 Decoder support non-multiple of 16 frame height and width?

H.264 bit-streams with non-multiple of 16 frame-height and frame-width are supported. Decoder will generate output frames of non–multiple of 16 dimensions only. There will be no padding applied by the decoder.

However height and width values used while creating the decoder instance must be multiple of 16. This is necessary because decoder’s internal memory allocations are in units of macroblocks.

What should be output buffer size in case of cropped resolution?

For H.264 test stream where cropped dimensions are indicated through the SPS (sequence parameter set), output buffers of the cropped resolution are sufficient.

Does H.264 Decoder support NAL stream decoding?

NAL stream decoding is supported. While using the decoder in NAL stream mode, NAL unit data of one complete frame should be accumulated and then passed to decoder with the information about number of NAL units in the frame, length of each NAL unit.

Correct Error code is not returned along with output buffer in NAL stream mode. What is the reason for this behaviour? (v.1.30.000.12 or earlier).

In case of NAL stream mode of decoding, if a bit-stream error is found decoder would return from the process call with the correct error code. But the output buffer would be returned only in the next process call after more data is available. The error code was not carried forward in this case and the output buffer may contain corrupted picture though the error code would indicate no error. This issue was resolved in v.1.30.000.13, the correct error code is now sent with the output buffer.

Can the output buffer pointer be NULL in any case?

Output buffer pointer will be NULL in two cases:

• If maxDisplayDelay is set to be N (non zero) then for first N process calls the output buffer will be NULL.
• In case of NAL stream decoding, if sufficient data is not available to decode a frame, decoder will return NULL buffer expecting more input in next process call. In such scenario the same output buffer should be passed to the decoder in the next process call.

What is decoder behavior in case of start code in NAL stream mode?

Post v.1.30.000.13 H.264 decoder signals error, if a start code is found in NAL stream data. The decoder will try to continue decoding assuming a new NAL unit starts at that point.

If XDM_PARSE_HEADER is used, decoder does not return correct height and width (v.1.30.000.12 or earlier)

In case, only header parsing (SPS and PPS) was requested decoder could not return correct values for frame height and width. This issue is fixed in decoder v1.30.000.13

TI logo not visible correctly in evaluation version of decoder.

The issue was seen in case of non-multiple of 16 frame width. This issue has been fixed in v1.30.000.13

What is the decoder behavior in case of unsupported profile/level stream?

H.264 BP decoder supports streams up to Level 3. In case of a H.264 bitstream of higher profile or level is encountered, as an error resiliency feature, error is not reported right away, the decoder attempts to decode the stream. Only when decoding is not possible (for e.g. because of unsupported features like B frames, insufficient number of available frame buffers), the decoder will report error.

Output frames seem to be out of order. What could be the reason?

In cases where frame order in encoded bitstream is different than the display order, some display delay is necessary for proper display. For e.g. for the bit-stream ‘hcbp1_hhi_a.264’, minimum maxDisplayDelay required is eight, correspondingly minimum nine output frame buffers are also required.

Is it possible to configure the input bitstream format (Byte stream format or NAL stream format) at runtime?

The H.264 decoder supports (v1.30.000.14 onwards) configuration of input bitstream format through a control API. This feature could be used to reconfigure the input bitstream format being used, if it is different than that used while instantiating the decoder.

H.264 Main Profile decoder related queries

Does H.264 Decoder support decoding of test streams with no IDR frames?

Main Profile H.264 Decoder v1.14 supports test streams with no IDR frames. This version of Decoder is able to decode from the first I frame onwards.

In case of some non IDR streams, few frames after the first I frame appear to be corrupted. What is the reason for this behavior?

For some P or B frames after the Intra frame, the reference frame might have been encoded before the Intra frame (cut stream). These frames cannot be decoded correctly, and the decoder will report error for these frames. Application can discard such frames after reading the error code.

H.264 MP decoder is returning Invalid outArgs after reset is called.

If the H.264 MP decoder were reset after decoding one field of an interlaced frame, any further decoding would result in invalid values in outArgs structure. This observation was for the case when decoder input stream is switched in-between decoding. This issue was resolved in v1.14.010.03.

Frames are not displayed in correct order. What could be the issue?

In case of H.264 MP decoder v1.14.007, incorrect output frame order was seen when the PictureOrderCount (POC) changed from negative to positive. The bug was fixed in v.1.14.010.04

For interlaced content, if a field is missing because of corruption, the frames are displayed in wrong order.

For missing field case the decoder attempts error concealment and sends the frame for display. However the calculation of display order was incorrect in missing field case. This issue has been resolved in v.1.14.010.04

Interlaced content is not indicated correctly in status variable

The H.264 MP decoder wrongly returned content type as progressive for frame coded interlaced content. This issue has been resolved in v1.14.010.04

CIF, QCIF streams are not properly decodable if decoder instance is created using that resolution.

Decoder output was not correct for CIF or QCIF streams if the H.264 MP decoder was configured with height and width less than D1. This issue has been resolved in decoder v.1.14.010.03.

See Also

• Codec_FAQ