Format of H.264 decoder configuration record taken from .mp4

Question

I am inspecting decoder configuration record contained in .mp4 video file recorded from Android devices. Some devices have strange or incorrect parameters written in decoder configuration record.

Here is sample from Galaxy Player 4.0 which is incorrect:

DecoderConfigurationRecord: 010283f2ffe100086742000de90283f201000568ce010f20
       pictureParameterSetNALUnits : 68ce010f20
       AVCLevelIndication : 242
       AVCProfileIndication : 2
       sequenceParameterSetNALUnits : 6742000de90283f2
       lengthSizeMinusOne : 3
       configurationVersion : 1
       profile_compatibility : 131
       profile_idc : 103
       constraint_set : 16
       level_idc : 0

AVCLevelIndication == 242 is wrong because standard states 51 is the highest value.

AVCProfileIndication should be in (66, 77, 88, 100, 120, ..)

profile_compatibility is called constraint_set?_flags and 2 least significant bits are reserved and seposed to be equal to 0

This is how it should look like:

DecoderConfigurationRecord: 0142000dffe100086742000de90283f201000568ce010f20
       pictureParameterSetNALUnits : 68ce010f20
       AVCLevelIndication : 13
       AVCProfileIndication : 66
       sequenceParameterSetNALUnits : 6742000de90283f2
       lengthSizeMinusOne : 3
       configurationVersion : 1
       profile_compatibility : 0
       profile_idc : 103
       constraint_set : 16
       level_idc : 0

How can AVCLevelIndication and AVCProfileIndication be deduced from profile_idc and level_idc ?

Is there a way to check or possibly fix wrong parameters by comparing them to SPS parameters ?

jgh · Accepted Answer · 2012-08-08T16:53:28.467

6

level_idc is 10 * level. i.e. if you're using level 3.1, it will be 31.

profile_idc is specified in Annex A of ISO/IEC 14496-10. Baseline profile is 66, Main Profile is 77 and Extended Profile is 88 for example.

Additionally, you can see the syntax for the SPS RBSP and PPS RBSP in section 7.3.2.1 and 7.3.2.2 respectively. Note ue(x) and se(x) indicate unsigned exponential golomb coding and signed exponential golomb coding.

Edit: My apologies. The AVCProfileIndication and AVCLevelIndication should be the same as profile_idc and level_idc

edited Aug 08 '12 at 16:53

answered Aug 08 '12 at 16:43

jgh

2,017
14
13

in my example profile_idc==103 how that translates to 66 (baseline profile) ? and level_idc==0 how that translates to 13 (level 1.3) ? – Alex Aug 08 '12 at 18:20
It appears the endianness is backward somewhere along the line. The `AVCProfileIndication`, `profile_compatibility`, and `AVCLevelIndication` are bytes 1 through 3 in the SPS NALU. i.e. you should disregard 0x67 because that indicates it's an SPS NALU, and then use `0x42`, `0x00`, `0x0d` for those values. However, it appears to be using `0xF2`, `0x83`, and `0x02` from the back of the NALU data, and going in the wrong direction. `0xF2` gives you 242, `0x83` gives you 131 for profile_compatibility, and `0x02` gives you a level of 2. – jgh Aug 08 '12 at 21:00
1

Also, this profile_idc == 103 indicates that you're getting profile_idc = 0x67 which is actually the NALU Header. `0x67 & 0x1F == 0x7` SPS type is 0x7. You want to start at the next byte, 0x42. – jgh Aug 08 '12 at 22:13
That is correct. Somehow I would never have noticed such mistake. – Alex Aug 08 '12 at 22:37

Format of H.264 decoder configuration record taken from .mp4

1 Answers1

Linked