Searching for magic code is not a guarantee about iamf

[sunghee-hwang]

We may need to add this kind of logic get sync pattern to Informative Annex.

The logic to get sync pattern would be like this;

• Step1: Check if the first 7bits is 1111100 or 1111110
• Step2: Check if the next 1 bit is 0(no extension) or 1 (extension)
• Step3-1: If there is no extension, then check if # of bytes of obu_size field and followed by ia_code.
• Step3-2: If there is extension, check if # of bytes of obu_size field, followed by # of bytes of extension header indicated by extension_header_size field and followed by ia_code.

So, the size of sync pattern would be regarded as at least 38 bits = 6bits (in step1) + 32bits (in step3). (There is a condition in step2, so actual bits would be more than this)
Its probability to occur within other OBUs in accident is about 2.7 x 10 ^(-11).
If we assume IAMF bitrate of 768kbps, it may occur one time per 3.5 x 10^5 second (one per 97.6 hours = about 4 days). Even broadcasting scenario, we have upper-layer signal which its payload is IAMF. So, actually probability in real world is much lower than this.

In addition, if we still feel uncomfortable, then we may add one more logic like this.

• Step4: Check if Magic Code OBU and followed by 7 bits = 0000000 or 0000010 (Codec Config OBU).
• (In this case, 2^6 = 64 times than the previous. I.e. one per 256 days)

If we need more,
-Step5: Check if Codec Config OBU and followed by 7 bits = 0000100 or 0000110. (one per 44.9 years)

[tdaede]

That seems like enough for me.

Personally, I'd actually like to discourage seeking around for a magic code in general. Magic codes only occur at the beginning of a stream (so they aren't useful for random seeking), and we currently require streams to start with a magic code, so the utility of them is pretty low.

I would expect that all other container mappings would provide their own synchronization primitives if needed, e.g. in the case of ts https://aomediacodec.github.io/av1-mpeg2-ts/#start-code-based-format

[sunghee-hwang]

Thank you for your opinion.
For the case of that SG members prefer to have more bits for ia_code, I listed a few candidate for it. Please see PR #447. I think that we can make a final decision on the call.