Some historic background: I'm currently working with Wowza and attempting to decode the AMFPackets that come from the IMediaStream. The video packets will have a 5-byte header and the first packet is the codec configuration.
So far in my inspecting the codec configuration matches the ISO/IEC 14496-15 AVCDecoderConfigurationRecord layout. However, I'm having trouble decoding the SPS and PPS units.
17 00 00 00 00 01 4D 00 15 03 01 00 2F 67 4D 40 15 96 52 02 83 F6 02 A1 00 00 03 00 01 00 00 03 00 28 E0 60 03 0D 40 00 49 3E 7F 18 E3 03 00 18 6A 00 02 49 F3 F8 C7 0E D0 B1 68 90 01 00 04 68 EB 73 52
17 00 00 00 00
67 4D 40 15 96 52 02 83 F6 02 A1 00 00 03 00 01 00 00 03 00 28 E0 60 03 0D 40 00 49 3E 7F 18 E3 03 00 18 6A 00 02 49 F3 F8 C7 0E D0 B1 68 90
Assuming this is a NAL unit containing SPS type: (Using ITU-T H.264 06/2011 7.3.1 NAL unit syntax)
Assuming the SPS payload follow: (Using ITU-T H.264 06/2011 7.3.2.1.1 Sequence parameter set data syntax)
Assuming this is only a SPS: (Using ITU-T H.264 06/2011 7.3.2.1.1 Sequence parameter set data syntax)
It looks like it's the former NAL unit header + SPS record, and I doubt it's bad data because every captured config packet is the same, but what throws me off is why is the forbidden 0 bit set to 1?
Thanks
I found the problem... too much staring at 1's and 0's and you'll miss one (pun intended).
67 4D 40 15...
Assuming this is a NAL unit containing SPS type: (Using ITU-T H.264 06/2011 7.3.1 NAL unit syntax)
First byte: 67 = 1100111
This is wrong because 1100111 is only 7-bits. I did the conversion using MS Calculator and it stripped the leading 0. The correct binary is 01100111, and there's the forbidden zero bit.
Thanks to those who attempted to solve this question.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With