Fix codec parsing for AVC streams

[Qizot]

This PR will...

Fix the codec parsing for MP4 AVC streams.

Why is this Pull Request needed?

Previously the codec was wrongly parsed (the extraction of profile + compatibility + level) at a wrong offset.

From a certain version, the source buffer started to get created based on codecs present in init segment instead of the playlist's codecs, resulting in an error since e.g. profile was zero.

Are there any points in the code the reviewer needs to double check?

Resolves issues:

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[robwalch]

Hi @Qizot,

From a certain version, the source buffer started to get created based on codecs present in init segment instead of the playlist's codecs, resulting in an error since e.g. profile was zero.

From what version?

Have you filed a bug?

We have not seen this issue and will need to reproduce and conform the issue before reviewing and considering this PR. Did we miss it because only some assets with profile 0 that produce it?

[Qizot]

Hey @robwalch

I will provide you with an example tomorrow and the exact walkthrough of the mp4 boxes and their sizes.

[Qizot]

@robwalch Okay, right now I have a broader explanation of what happened.

The problem comes from a fact that avc3 doesn't need to specify SPS/PPS values in avcC box and the mp4-tools basically tries to read profile + compatibility + level from a place, where SPS is usually present.

Note that both avcC box and SPS contain such information (it is duplicated).

Example stsd box content for avc3 format

 [
  0, 0, 0, 0, 0, 0, 0, 1,
  0, 0, 0, 117, // avc3 box size
  97, 118, 99, 51, // avc3 type
  0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 128, 4, 56,
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 24, 255, 255, // avc3 box data
  0, 0, 0, 15, // avcC box size
  97, 118, 99, 67, // avcC type
  1, // configurationVersion
  66, 0, 42, // profile + compability + level
  255, // lengthSizeMinusOne (3 + 63 << 2)
  224, // SPS size (0 + 7 << 5)
  0, // PPS size
  0, 0, 0, 16, // pasp box size but it doesn't matter
  112, 97, 115, 112, 0, 0, 0, 1, 0, 0, 0, 1
]

Example stsd box content for avc1 format

[
 0, 0, 0, 0, 0, 0, 0, 1,
 0, 0, 0, 138, // avc1 box size
 97, 118, 99, 49, // avc1 type
 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 128, 4, 56, 0, 72, 0, 0, 0, 72, 0,
 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 24, 255, 255, // avc1 box data
 0, 0, 0, 52, // avcC box size
 97, 118, 99, 67, // avcC type
 1, // configurationVersion
 100, 0, 42, // profile + compatibility + level
 255, // lengthSizeMinusOne (3 + 63 << 2)
 225, // SPS size (1 + 7 << 5)
 0, 29, // SPS entry size
 103,
 100, 0, 42, // profile + compatibility + level
 172, 211, 1, 224, 8, 159, 151, 1, 106, 4, 0, 4, 128, 0, 0, 3, 0, 170, 14, 154, 0, 7, 140, 24, 156, // rest of SPS
 1, // PPS count
 0, 4,  // PPS entry size
 104, 239, 188, 176 // PPS data
] 

Fix

If you look closely the current implementation looks at the place of SPS when it doesn't need to (and for avc3 format it even breaks). It is exactly 8 bytes after a place where the information is present in avcC box therefore the fix is to move the offset back by 8 bytes.

Sample streams

Example avc3 stream:
https://globetrotter-vst-staging.edgecompute.app/v1/vod/969991b6-37cf-45c8-b919-fd789c135e36/master.m3u8

Example avc1 stream:
https://stream.mux.com/v69RSHhFelSm4701snP22dYz2jICy4E4FUyk02rW4gxRM.m3u8